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.
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.dpuf2.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 DTN ION 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.dpuf3.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). |
| ION-DTN | Please download it from SourceForge directly. You must use ION version 3.3.0. |
| DTN2 | Please download it from SourceForge. Please use version 2.9 as that is the version with IPND support. |
| IBR | Please download version 1.0.1 from here. |
| Python IPND | Please download it from the forum after you register for the challenge. |
1. This challenge will use the class diagrams and implementation notes in the provided TCUML to complete the IPND implementation started by Part 1.
2. In addition to the implementation, you will develop unit and system tests to demonstrate your IPND implementation.
If there are any apparent gaps or discrepancies in the diagrams, please bring it up immediately on the forum.
You can refer to the assembly tutorial for additional information on challenge deliverables if you are new to competing on Assembly or Code challenges.
3.2. Challenge Task: Implementation
1. Complete the implementation for service definitions - 2.6.3 Services
Reserved Constructed: CLA-TCP-v6, CLA-UDP-v6, CLA-TCP-HN, CLA-UDP-HN;
Private Constructed: support the creation of private services using the contrived example in Appendix B of the Internet Draft.
2. The IBR DTN distribution supports the use of Neigbhorhood Bloom Filters or NBF for short - 2.6.4. Neighborhood Bloom Filter but DTN2 doesn't currently support NBF.
Please update Python IPND to use the hash algorithm used by IBR so it can exchange beacons containing NBF info with IBR nodes. DTN2 nodes that receive beacons containing NBF info will simply ignore the info since they do not know how to interprete them.
3. Ensure that our Python IPND implementation can interoperate with DTN2 and IBR nodes on the same network. The winning submission to a challenge that demonstrates how to set up a multi-node DTN network consisting of DTN2, IBR and ION nodes will be provided once a winner is chosen.
Detailed implementation notes have been provided here.
3.3. Challenge Task: Tests
To ensure that the proof of concept will conform to the IPND spec, you will also provide tests: unit and system tests.
1. You will develop automated tests that provide adequate code coverage of the functional requirements. The tests will handle: pre- and post- conditions, test data for scenario setup, expected outcomes for accuracy and failure conditions, etc.
2. System tests demonstrate the use of the IPND protocol between multiple nodes. The tests will test all network communications between multiple nodes.
For instance, if node 1, node 2 and node 3 constitute a 3-node local network, each node should be able to learn of the existence the other 2 nodes via the IPND protocol.
Part 2 of this challenge will improve upon neighbor discovery to be implementation independent i.e. neighbor discovery will be independent of the IPND tool used by other nodes. Node 1 could be running DTN2 IPND on port 4556, node 2 could be running IBR IPND on port 4556 while node 3 could be running an instance of IPND on port 4556 that has been built so far.
4.0. Challenge Deliverables
Please submit, in a compressed archive:
- Deployment Guide (DG): describing how to deploy and test your Python IPND implementation;
- Python code: implementing the requirements;
- Python tests: that exercise your implementation using unit and system tests.
Please download the template on which to base your deployment guide on from here.
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.