3.3. Challenge Task: Implementation

1. The ION-DTN code base is fairly large, so you are encouraged to familiarize yourself with its architecture by reviewing the document ION.pdf in the ion-open-source folder after extracting ION v3.3.0 locally. You should review sections: 1.1, 1.2, 1.3, 1.4, 1.5 and 1.6.1 that document salient aspects of the design and operation of ION-DTN.

2. ION-DTN was designed to run on flight environments, which are typically based on Real Time Operating Systems (RTOS). Many RTOS improve processing determinism by omitting the support for protected memory models that is provided by Unix-like operating systems: all tasks have direct access to all regions of system memory. ION-DTN therefore had to be designed with no expectation of memory protection.

Competitors must be cautious with respect to the memory management in ION-DTN because it is different from traditional C memory management, therefore, malloc can NOT be used. ION-DTN provides its own mechanisms for memory management / data sharing via Personal Space Management (PSM), Spacecraft Data Recorder (SDR), Memmgr etc. Competitors are advised to read section 1.5 of ION.pdf to get familiar with these memory/resource management modules.

3. Wherever possible, please adhere to the C coding guidelines in the ION Style Guide.

4. The ION IPND code now resides in a new ion-open-source/bp/ipnd directory. Please put all the common definitions in the ipndP.h file in that directory.

5. PyIPND expresses service definitions elegantly using XML but we would like to avoid the use of XML in ION due to absence of a standard XML parser for C that can guarantee code portability. For Part 2, please explore ways in which service definitions can be expressed in a human-readable textual format that does not require a (non-standard) parser like XML.

6. PyIPND does not provide any Convergence Layer Adapters (CLA) to be able to fulfill the requirements of the IPND protocol with respect to notifying dependent CLAs of the discovery of a new node, or loss of contact to a previously discovered node, as described in section 2.7. IPND and CLAs, because it is a prototype and not a proper DTN distribution like ION.

Your ION IPND port from PyIPND must implement this requirement by notifying dependent CLAs via the eureka interface (ion-open-source/bp/include/eureka.h).

3.3.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.3.2. ION-DTN Setup

PyIPND includes several Docker files that demonstrate how to install ION-DTN (and other DTN distributions) on Ubuntu Linux which you'll find in docker/templates/. You should be able to adapt the instructions in the Docker file for ION-DTN (docker/templates/ion.dockerfile) to suit your development environment.

You can refer to the assembly tutorial for additional information on challenge deliverables if you are new to competing on Assembly challenges.

3.4. Challenge Task: Tests

Your system tests should demonstrate the use of the IPND protocol between multiple nodes running different IPND implementations. Please test your implementation can interoperate with DTN2 and PyIPND.

For instance, if node 1 is running DTN2, node 2 is running PyIPND and node 3 is running ION-DTN and they constitute a 3-node local network, each node should be able to learn of the existence the other 2 nodes via the IPND protocol.

4.0. Challenge Deliverables

Please submit, in a compressed archive:

• Deployment Guide (DG): describing how to deploy and test your ION IPND implementation;
• Updated ION-DTN code: implementing the requirements;
• Updated Docker files and Python scripts: that exercise your implementation using system tests.

Please base your deployment guide on the deployment guide produced for Part 1 here but ensure you highlight your changes so it is easy for reviewers to identify your modifications.