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.
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 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.
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 - 21). |
| ION-DTN | Please request access to it on GitLab in the forum after you register for the challenge. You must use our modified version of ION 3.3.0. |
| ION Style Guide | ION-DTN C coding conventions. Available from the forum after you register for the challenge. |
| Test Plan | The test plan is available from the forum after you register for the challenge. |
All the files for the project are hosted on GitLab. You will need to request access to the GitLab repository in the forum if you get a HTTP 404 not found error.
3.1.1. Technologies
- Linux (Ubuntu 14.04.2 LTS recommended)
- C
- GCC (version 4.8.1 is recommended)
- Make (version 3.82 is recommended)
- Python 2.7.9
- ION-DTN 3.3.0
- Docker 1.5.0
3.1.2. ION-DTN Setup
Please refer to the deployment guide (DG) for instructions on how to install ION-DTN (and other DTN distributions) on Ubuntu Linux which you'll find in the git repository. You should be able to adapt the instructions in the Docker file for ION-DTN (docker/templates/ion.dockerfile) to suit your development environment.
3.2. Challenge Requirements
This challenge will fix all defects that were uncovered in the ION IPND implementation by a Test Suites challenge including any issues that may lead to segmentation faults and buffer overflows.
1. Out of 52 test cases exercised by the Test Suites challenge, 34 test cases pass but the following 18 test cases give a warning, fail or error out: 14, 90, 92 - 94, 105, 106, 109 - 112, 140 - 142, 144, 146 - 148. The winning Test Suites submission is attached to the forum.
2. In addition to fixing the defects identified above, you need to add assertions to the ION IPND code to mitigate against the scenarios described in the following test cases from the Test Plan which exercise the "send-side" of ION IPND implementation when invalid values are specified in ipnd.rc: 37, 38, 40, 41, 42, 149.
3. There are a few CHKZERO and CHKERR assertions that fail when the IPND daemon is started up. For instance, after executing:
docker run -t -d --privileged=true --name node4 --hostname node4 -e DOCKER_IP="10.0.1.4/16" -e ION_OPTS="/etc/ipnd_unicast_nbf.rc" -e DOCKER_GATEWAY="10.0.0.1" dtn_test/ion
The following assertion failures can be observed in the log file attached to the forum:
[2015/06/08-22:36:08] at line 485 of ici/library/lyst.c, Assertion failed. (elt)
...
[2015/06/08-22:36:08] at line 448 of ici/library/lyst.c, Assertion failed. (elt)
...
[2015/06/08-22:36:08] [2015/06/08-22:36:08] at line 531 of ici/sdr/sdrlist.c, Assertion failed. (sdrFetchSafe(sdrv))
...
[2015/06/08-22:36:08] at line 170 of bp/ipn/libipnfw.c, Assertion failed. (ionLocked())
Please investigate and fix all assertion failures that are present. The first one is likely due to ctx->neighbors being an empty lyst when the IPND daemon is started up for the first time; the fix should be as simple as checking for when the length of the lyst is zero before calling lyst_first() inside helper.c#findIpndNeighbor().
4. Beacon sequence numbers should start from 1 and not 0 as is currently done by ION IPND.
Reviewers will be expected to use the provided Test Suites submission written in Python to exercise the ION IPND implementation to check and ensure that all tests pass.
3.2.1. Automated Tests
For the challenge requirements (item #2) that require adding assertions, you may test them using automated tests in C. You should be able to leverage ion-open-source/tests/library/[testutil.h, ionstart.c] etc to launch these tests. An example of how they are used can be seen in ion-open-source/tests/1000.loopback/dotest.c.
3.2.2. System Tests
The ION IPND implementation should still continue to interoperate with DTN2 and PyIPND.
Note that:- IBR implements version 2 of the IPND spec which is not fully compatible with version 4 of the IPND spec that ION IPND, PyIPND and DTN2 implement.
- DTN2 does not implement all optional aspects of the IPND protocol like the use of NBF to determine link bi-directionality.
4.0. Challenge Deliverables
Please submit, in a compressed archive:
- Deployment Guide (DG): describing how to deploy and run your test scripts against the ION IPND implementation;
- Code: all code necessary for testing including updated ION-DTN code, updated Docker files and Python scripts.
Note that the winner will be required to merge the code with the master branch as part of final fixes.
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.