Nsnam - User contributions [en]

GSOC2022NeighborCacheFinalReport

2022-10-11T05:10:48Z

Zhiheng: /* Project Overview */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

= Merge Requests and Commits =

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc
* To run the test: ./test.py -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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

= Acknowledgement =

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.

GSOC2022PerfectArp

2022-09-28T00:29:42Z

Zhiheng: /* Project Overview */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]
* '''Final Report:'''[https://www.nsnam.org/wiki/GSOC2022NeighborCacheFinalReport link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

'''Week8 - Week9'''

Duration: August 1 - August 14

I'm not fully involved in GSoC program these days because of some personal issue

* Update MR based on comments.
* add function to flush all auto-generated entries
* add remove callbacks in ipv4interface to enable dynamical perfect cache
* delete the double wifi example and modify the simple example to a detailed one to show all API and sending a data stream to show how perfect cache reduces the packet drop rate in some situation.

'''Week10 - Week11'''

Duration: August 15 - August 28

* Complete the update on the static neighbor cache, which is ready to be merged.
* Update the MR of dynamic neighbor cache based on comments.

'''Week10 - Week11'''
Duration: August 29 - September 4

* [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 MR]on static neighbor cache has been merged.
* Update the [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 MR] of dynamic neighbor cache based on comments.
* Refactor on NUD_STATE process on icmpv6.

GSOC2022NeighborCacheFinalReport

2022-09-19T05:33:03Z

Zhiheng: /* Merge Requests and Commits */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

= Merge Requests and Commits =

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc
* To run the test: ./test.py -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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

= Acknowledgement =

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.

GSOC2022NeighborCacheFinalReport

2022-09-12T07:04:12Z

Zhiheng: /* Steps to build the code for Phase 2 */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

= Merge Requests and Commits =

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc
* To run the test: ./test.py -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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

= Acknowledgement =

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.

GSOC2022NeighborCacheFinalReport

2022-09-10T07:03:46Z

Zhiheng: /* Acknowledgement */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

= Merge Requests and Commits =

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

= 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

= Acknowledgement =

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.

GSOC2022NeighborCacheFinalReport

2022-09-10T07:01:39Z

Zhiheng:

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

= Merge Requests and Commits =

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

= 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

= Acknowledgement =

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, 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.

GSOC2022NeighborCacheFinalReport

2022-09-10T07:00:58Z

Zhiheng:

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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.

= Merge Requests and Commits =

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

= 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

= Acknowledgement =

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, 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.

GSOC2022NeighborCacheFinalReport

2022-09-10T06:50:47Z

Zhiheng:

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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.

= Merge Requests and Commits =

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

= 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

= Acknowledgement =

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, 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.

GSOC2022NeighborCacheFinalReport

2022-09-10T06:47:21Z

Zhiheng:

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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.

= Merge Requests, Commits, and Project Details =

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic link]
|}

= 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 link]

= 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

=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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

= Acknowledgement =

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, 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.

GSOC2022NeighborCacheFinalReport

2022-09-10T06:46:34Z

Zhiheng:

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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.

== Merge Requests, Commits, and Project Details ==

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic link]
|}

== 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 link]

== 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

==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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

== Acknowledgement ==

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, 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.

GSOC2022NeighborCacheFinalReport

2022-09-10T06:45:39Z

Zhiheng:

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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.
== Merge Requests, Commits, and Project Details ==

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic link]
|}

== 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 link]

== 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

==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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

== Acknowledgement ==

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, 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.

GSOC2022NeighborCacheFinalReport

2022-09-10T06:05:21Z

Zhiheng:

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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.
== Merge Requests, Commits, and Project Details ==

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic link]
|}

== 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 link]

== 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

==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/neighbor-cache-example.cc
* To run the test: ./test.py -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/neighbor-cache-dynamic.cc

GSOC2022NeighborCacheFinalReport

2022-09-10T05:38:33Z

Zhiheng: /* Project Overview */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com 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 in simulations that are focused 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.
== Merge Requests, Commits, and Project Details ==

Project Wiki Page: [https://www.nsnam.org/wiki/GSOC2022PerfectArp ''GSOC2022PerfectArp'']

Project Plan: [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit#heading=h.s3wcskgocqq ''link'']

{| class="wikitable"
|+ Merge Requests
|-
! No. !! Name !! Status !! Commit
|-
| [1] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 Internet: GSoC-22 generate ARP/NDISC cache automatically] || Merged || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commit/87fb2ddcbf1132416e32a0965f61ac2bcc5ac6b2 link]
|-
| [2] || [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 internet: GSoC-22 dynamic neighbor cache] || Reviewing || [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/phase2-dynamic link]
|}

== 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: [https://gitlab.com/ZhiHengD/ns-3-dev/-/commits/gsoc 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 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: [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 link]

== 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 [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1035 MR].

GSOC2022NeighborCacheFinalReport

2022-09-10T05:07:39Z

Zhiheng:

GSOC2022NeighborCacheFinalReport

2022-09-10T04:52:57Z

Zhiheng:

GSOC2022NeighborCacheFinalReport

2022-09-10T04:52:12Z

Zhiheng: /* Phase 1 */

GSOC2022NeighborCacheFinalReport

2022-09-10T04:33:56Z

Zhiheng: /* Phase 1 */

GSOC2022NeighborCacheFinalReport

2022-09-10T04:33:11Z

Zhiheng: /* Phase 1 */

GSOC2022NeighborCacheFinalReport

2022-09-10T04:31:58Z

Zhiheng: /* Phase 1 */

GSOC2022NeighborCacheFinalReport

2022-09-10T04:31:29Z

Zhiheng: /* Phase 1 */

GSOC2022NeighborCacheFinalReport

2022-09-10T04:30:58Z

Zhiheng:

GSOC2022NeighborCacheFinalReport

2022-09-06T08:00:42Z

Zhiheng: /* Merge Requests, Commits, and Project Details */

GSOC2022NeighborCacheFinalReport

2022-09-06T08:00:15Z

Zhiheng: Created page with "{{TOC}} Back to GSoC 2022 projects = Project Overview = * '''Project Name:''' Perfect ARP and NDP * '''Student:''' [mailto:..."

GSOC2022PerfectArp

2022-09-06T07:00:21Z

Zhiheng: /* Weekly Reports */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

'''Week8 - Week9'''

Duration: August 1 - August 14

I'm not fully involved in GSoC program these days because of some personal issue

* Update MR based on comments.
* add function to flush all auto-generated entries
* add remove callbacks in ipv4interface to enable dynamical perfect cache
* delete the double wifi example and modify the simple example to a detailed one to show all API and sending a data stream to show how perfect cache reduces the packet drop rate in some situation.

'''Week10 - Week11'''

Duration: August 15 - August 28

* Complete the update on the static neighbor cache, which is ready to be merged.
* Update the MR of dynamic neighbor cache based on comments.

'''Week10 - Week11'''
Duration: August 29 - September 4

* [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 MR]on static neighbor cache has been merged.
* Update the [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 MR] of dynamic neighbor cache based on comments.
* Refactor on NUD_STATE process on icmpv6.

GSOC2022PerfectArp

2022-09-05T05:01:50Z

Zhiheng: /* Weekly Reports */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.
[http://www.example.com link title]
'''Week8 - Week9'''

Duration: August 1 - August 14

I'm not fully involved in GSoC program these days because of some personal issue

* Update MR based on comments.
* add function to flush all auto-generated entries
* add remove callbacks in ipv4interface to enable dynamical perfect cache
* delete the double wifi example and modify the simple example to a detailed one to show all API and sending a data stream to show how perfect cache reduces the packet drop rate in some situation.

'''Week10 - Week11'''
Duration: August 15 - August 28

* Complete the update on the static neighbor cache, which is ready to be merged.
* Update the MR of dynamic neighbor cache based on comments.

'''Week10 - Week11'''
Duration: August 29 - September 4

* [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 MR]on static neighbor cache has been merged.
* Update the [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 MR] of dynamic neighbor cache based on comments.
* Refactor on NUD_STATE process on icmpv6.

GSOC2022PerfectArp

2022-09-05T04:55:44Z

Zhiheng: /* Weekly Reports */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

'''Week8 - Week9'''

Duration: August 1 - August 14

I'm not fully involved in GSoC program these days because of some personal issue

* Update MR based on comments.
* add function to flush all auto-generated entries
* add remove callbacks in ipv4interface to enable dynamical perfect cache
* delete the double wifi example and modify the simple example to a detailed one to show all API and sending a data stream to show how perfect cache reduces the packet drop rate in some situation.

'''Week10 - Week11'''
Duration: August 15 - August 28

* Complete the update on the static neighbor cache, which is ready to be merged.
* Update the MR of dynamic neighbor cache based on comments.

'''Week10 - Week11'''
Duration: August 29 - September 4

* (https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012 MR]) on static neighbor cache has been merged.
* Update the [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1068 MR] of dynamic neighbor cache based on comments.
* Refactor on NUD_STATE process on icmpv6.

GSOC2022PerfectArp

2022-08-20T07:50:20Z

Zhiheng: /* Weekly Reports */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

'''Week8 - Week9'''

Duration: August 1 - August 14

I'm not fully involved in GSoC program these days because of some personal issue

* Update MR based on comments.
* add function to flush all auto-generated entries
* add remove callbacks in ipv4interface to enable dynamical perfect cache
* delete the double wifi example and modify the simple example to a detailed one to show all API and sending a data stream to show how perfect cache reduces the packet drop rate in some situation.

GSOC2022PerfectArp

2022-08-20T07:49:58Z

Zhiheng: /* Weekly Reports */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

'''Week8 - Week9'''

Duration: August 1 - August 14

I'm not fully involved in GSoC program these days./because of some personal issue

* Update MR based on comments.
* add function to flush all auto-generated entries
* add remove callbacks in ipv4interface to enable dynamical perfect cache
* delete the double wifi example and modify the simple example to a detailed one to show all API and sending a data stream to show how perfect cache reduces the packet drop rate in some situation.

GSOC2022PerfectArp

2022-08-20T07:17:39Z

Zhiheng: /* Weekly Reports */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

'''Week8 - Week9'''

Duration: August 1 - August 14
I'm not fully involved in GSoC program because of some personal issue

* Update MR based on comments.
* add function to flush all auto-generated entries
* add remove callbacks in ipv4interface to enable dynamical perfect cache
* delete the double wifi example and modify the simple example to a detailed one to show all API and sending a data stream to show how perfect cache reduces the packet drop rate in some situation.

GSOC2022PerfectArp

2022-08-20T07:03:08Z

Zhiheng: /* Milestones and Deliverables */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 7

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Write examples and tests for them
* Update documentation

'''Phase 2'''

Duration: Week 8 to Week 10

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Write examples and tests for them
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

GSOC2022PerfectArp

2022-08-02T05:57:52Z

Zhiheng: /* Weekly Reports */

{{TOC}}

Back to [[Summer_Projects#Google_Summer_of_Code_2022 | GSoC 2022 projects]]

= Project Overview =

* '''Project Name:''' Perfect ARP and NDP
* '''Student:''' [mailto:dzh2077@gmail.com Zhiheng Dong]
* '''Mentors:''' Tommaso Pecorella, Ameya Deshpande, Manoj Kumar Rana
* '''Google page:''' https://summerofcode.withgoogle.com/programs/2022/projects/DdUT09pZ
* '''Project Goals:''' 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.). Perfect ARP/NDP can ensure every ARP/NDP look-up hits the cache so that no ARP messages or Neighbor discovery messages will be generated.
* '''Repository:''' https://gitlab.com/ZhiHengD/ns-3-dev
* '''About Me:''' I’m a first-year computer science graduate student from University of Southern California, US. I got my bachelor’s degree in computer science from University of Wisconsin- Madison, US. I began my graduate study in August 2021. I’m interested in computer networks and have good code experience in C and C++, I also did projects with Python, Java and JavaScript.
* '''Project Plan:''' [https://docs.google.com/document/d/1IT4FAJAOd91bzogkWMh3ybJxaswk8jOOtv_w_lIXZjo/edit?usp=sharing link]

= Milestones and Deliverables =
'''Phase 1'''

Duration: Week 1 to Week 3

* Enable ipv4 static perfect Arp
* Enable ipv6 static perfect Ndp
* Prepare examples and tests for them

'''Phase 2'''

Duration: Week 4 to Week 7

* Enable ipv4 dynamical perfect Arp
* Enable ipv6 dynamical perfect Ndp
* Prepare examples and tests for them

'''Phase 3'''

Duration: Week 8 to Week 10

* Handle DAD
* Enable ipv6 dynamical perfect Ndp
* Update documentation

= Weekly Reports =

'''Week1'''

Duration: June 13 - June 19

* Start working on IPv4 perfect Arp.
* Implemented an approach of creating subclass of ArpL3Protocol and ArpCache to dynamically create shared perfect cache.
* Handled interface up/down event in that approach.
* Tested IP neighbor cache flushing behavior about permanent entries in Linux.
* Determined to implement perfect cache in a more concise way, which is create static perfect cache first after discussing with mentors.

'''Week2'''

Duration: June 20 - June 26

* Implemented static perfect cache on both IPv4 and IPv6 by new helper class.
* Start adding tests and examples for perfect ARP/NDP
* Tested DAD behavior when interface disable ARP/NDP in Linux.

'''Week3'''

Duration: June 27 - July 3

* Implemented a subclass of Icmpv6L4Protocol for disable DAD
* Create two example for perfect ARP/NDP, the one is simple csma, another is double wifi. Meet problems when creating global routing in double wifi example, fix by using nix-vector routing instead.
* Draft Merge Request of static perfect cache with two examples. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]

'''Week4'''

Duration: July 4 - July 10

* Add test for perfect ARP/NDP.
* Add user-level API for updating perfect cache after IP address changes.
* Update MR based on comments. Fix mistakes and improve iteration logic. [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1012# link]
* Continue and refine the work on the dynamical perfect cache. Perfect cache updating will base on IP addresses added/removed instead of link up/down.

'''Week5'''

Duration: July 11 - July 17

* Update MR based on comments.
* Implement dynamical perfect ARP on locally shared cache per network.
* Add new perfect-arp-cache and perfect-arp-l3-protocol.
* Add addAddressCallback and removeAddressCallback to make it perfect caches updated dynamically by IP addresses change.
* Use a new data structure for perfect cache, ''std::unordered_map<Ipv4Address, Cache *, Ipv4AddressHash> PerfectCache;'' The key is network address and the value is the pointer to the unorder_map of normal caches. This new structure is used to differentiate a case that when an interface has multiple IP addresses from different networks, its perfect cache would contain entries from different networks.
* Overwite ''ArpCache::Lookup'',''ArpCache::Add'',''ArpCache::Remove'' for the new data structure of perfect ARP cache.

'''Week6'''

Duration: July 18 - July 24

* Update the ARP/NDISC cache to make them ordered.
* modify examples to show populate cache with interfaceContainer.
* replace the word perfect from the code with more technical words.

'''Week7'''

Duration: July 25 - July 31

* Refactor Icmpv6L4Protocol::ReceiveLLA and Icmpv6L4Protocol::HandleNA, change the nesting of if statement to switch case of NUD_STATE
* Add new NUD_STATE: STATIC_AUTOGENERATED. The entries generated by perfect ARP/NDP will use the new state
* Update printout in test and example, because of the new state and ARP/NDISC cache reorder.

GSOC2022PerfectArp

2022-07-18T20:56:39Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-07-18T20:54:16Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-07-11T00:36:26Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-07-10T20:04:04Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-07-10T20:02:26Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-06-28T05:51:22Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-06-20T06:30:41Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-06-20T06:23:54Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-06-19T06:12:30Z

Zhiheng: /* Weekly Reports */

GSOC2022PerfectArp

2022-06-19T06:12:17Z

Zhiheng: /* Milestones and Deliverables */

GSOC2022PerfectArp

2022-06-19T06:11:55Z

Zhiheng:

GSOC2022PerfectArp

2022-06-19T06:10:50Z

Zhiheng: /* Milestones and Deliverables */

GSOC2022PerfectArp

2022-06-19T06:08:54Z

Zhiheng: /* Milestones and Deliverables */

GSOC2022PerfectArp

2022-06-19T06:05:08Z

Zhiheng: /* Milestones and Deliverables */

GSOC2022PerfectArp

2022-06-19T06:00:20Z

Zhiheng: /* Project Overview */

GSOC2022PerfectArp

2022-06-19T06:00:09Z

Zhiheng: /* Milestones and Deliverables */

GSOC2022PerfectArp

2022-06-10T08:19:19Z

Zhiheng: /* Milestones and Deliverables */

GSOC2022PerfectArp

2022-06-10T08:18:40Z

Zhiheng: /* Milestones and Deliverables */

GSOC2022PerfectArp

2022-06-10T08:16:46Z

Zhiheng: /* Milestones and Deliverables */