DTN Neighbor Discovery - ION IPND Spec Conformance Test Plan

Register
Submit a solution
The challenge is finished.

Challenge Overview

1.0. Project Overview

Welcome to the NASA Disruption Tolerant Networking (DTN) project. DTN is an approach to computer network architecture that seeks to address the technical issues in heterogeneous networks that may lack continuous network connectivity.

Note that some literature may use the term Delay Tolerant Network which is also abbreviated as DTN - the two terms are used interchangeably.

DTN is designed to provide reliable end-to-end delivery of information between nodes, and to do so in an environment that experiences frequent connectivity disruptions and topology changes. Such a capability will directly support human and robotic space exploration, as well as have wide applicability to land-mobile and airborne terrestrial communications.

Learn more about DTN

 

Project Objectives

The goal of this project is very simple – and that is to update DTN ION so that it includes IP Neighbor Discovery (IPND).  

IPND is a method for otherwise oblivious nodes to learn of the existence, availability, and addresses of other DTN participants. IPND both sends and listens for small IP UDP announcement beacons that are addressed to an IP unicast, multicast, or broadcast address to discover specified remote neighbors, or unspecified local neighbors in the network topology.

Other DTN implementations, such as DTN2 and IBR, already support IPND. We now need to updated DTN ION to enable neighbor discovery capabilities as well. Neighbor discovery is also needed to enable future dynamic routing capability for the ION DTN implementation.

- See more at: http://www.topcoder.com/dtn/neighbor-discovery/#sthash.Mdb2QG1w.dpuf

2.0. Project Objectives

The goal of this project is fairly straightforward, to update an open source DTN implementation called DTN Interplanetary Overlay Network (DTN ION) so that it includes IP Neighbor Discovery (IPND) functionality. 

IPND is a method for otherwise oblivious nodes to learn of the existence, availability, and addresses of other DTN participants. IPND both sends and listens for small IP UDP announcement beacons that are addressed to an IP unicast, multicast, or broadcast address to discover specified remote neighbors, or unspecified local neighbors in the network topology.

Other DTN implementations, such as DTN2 and IBR, already support IPND. This project will design and implement updates to the ION-DTN code written in C to add neighbor discovery capabilities.

Neighbor discovery is also needed to enable future dynamic routing capability for the ION-DTN implementation.

 

Project Objectives

The goal of this project is very simple – and that is to update DTN ION so that it includes IP Neighbor Discovery (IPND).  

IPND is a method for otherwise oblivious nodes to learn of the existence, availability, and addresses of other DTN participants. IPND both sends and listens for small IP UDP announcement beacons that are addressed to an IP unicast, multicast, or broadcast address to discover specified remote neighbors, or unspecified local neighbors in the network topology.

Other DTN implementations, such as DTN2 and IBR, already support IPND. We now need to updated DTN ION to enable neighbor discovery capabilities as well. Neighbor discovery is also needed to enable future dynamic routing capability for the ION DTN implementation.

- See more at: http://www.topcoder.com/dtn/neighbor-discovery/#sthash.Mdb2QG1w.dpuf

3.0. Challenge Details

          

3.1. Challenge Documents

Document Description
IPND Internet Draft PDF version. The actual IPND spec is just 19 pages (page 3 - page 21).
Python IPND (PyIPND) Please download it from the forum after you register for the challenge.

 

  3.2. Challenge Task: Test Scenarios and QA Plan

The goal of this competition is to develop a quality assurance plan and test scenarios to ensure that our IPND implementation conforms to the IPND specification. You need to familiarize yourself with the IPND spec by reading the Internet Draft to identify test cases.

The plan and scenarios should cover both positive and negative outcomes. Each test should properly handle pre- and post- conditions, test data for scenario setup, expected outcomes for accuracy and failure conditions, etc.

1. There are mandatory and optional aspects of the IPND protocol. Your tests should be structured into required and optional tests, i.e. tests that can be used to demonstrate that an implementation implements all required aspects of the IPND protocol and tests that demonstrate that an implementation supports optional aspects of the IPND protocol.

Be sure to provide tests for service definitions which are regarded as optional in the IPND protocol - 2.6.3 Services   
        Reserved Constructed:
CLA-TCP-v4, CLA-UDP-v4, CLA-TCP-v6, CLA-UDP-v6, CLA-TCP-HN, CLA-UDP-HN, NBF-Hashes, NBF-Bits;
        Private Constructed: an implementation of the fictional private service in Appendix B of the Internet Draft is included in PyIPND.

2. The IPND protocol uses UDP to transport beacons. Due to the UDP being connectionless, to make it easy to reason about the tests, please further group the tests around inbound and outbound use cases.

3. Ensure that your test cases provide adequate code coverage of the aspects of the IPND protocol that have been left as implementation specific, in other words, provide test cases for the implementation specifics of PyIPND.

4. Please also provide comprehensive integration test cases that show that the Python IPND implementation can interoperate with other DTN nodes on the same network. The PyIPND submission includes some (manual) integration tests but you should aim for making all tests automated.

 

4.0. Challenge Deliverables

Please submit, in a compressed archive:

  • A QA Plan written in a Microsoft Word compatible document.
  • A Microsoft Excel compatible spreadsheet with the detailed Test Scenarios.

Please download the template on which to base your submission on from the forum after you register.



Final Submission Guidelines

1. Third Party Code/Libraries - All third party code/libraries must be open source and you must include the license in your submission. The license must allow us to modify/re-package the code as necessary. If you have any questions regarding this, please post in the forums. Submissions that include third party code without the proper license information will be disqualified if the third party code is found to be non-usable due to license restrictions.

2. Attribution/References - You must properly attribute and or reference any sentences, paragraphs or quotes that you cite in your text-based submission. If your submission is found to include text that has been copied and pasted from an online source without properly attributing the source, you will receive a not-so-nice email from the topcoder competition manager.

3. Spell Check - We understand that not all submitters will be native English speakers and that there will be spelling/grammatical mistakes. We request that you first run your submission through a grammar/spell checker before submission so as to fix simple mistakes.

ELIGIBLE EVENTS:

2015 topcoder Open

Review style

Final Review

Community Review Board

Approval

User Sign-Off

ID: 30048844