DTN Neighbor Discovery - DTN Network Setup Using Docker

Key Information

Register
Submit
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 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.dpuf

3.0. Challenge Details

          

3.1. Challenge Documents

The DTN IP Neighbor Discovery (IPND) specification document was published as an Internet Draft by the IETF. With the help of a specification challenge, we have converted the IPND spec into TopCoder's Application Requirements Specification (ARS) format.

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.

 

This challenge will use Docker to manage 3 different DTN implementations namely ION-DTN, DTN2 and IBR.

  1. You will provide 3 Docker images, one for each of the DTN distributions mentioned above.
  2. Then, you will demonstrate inter container communication, i.e. you will set up a Linux VLAN such that each container is assigned its own unique IP such that it can communicate with the other 2 containers, in addition to being reachable from the host (running the docker daemon).
  3. Additional details are provided in the next section but your deployment should appear identical to the diagram below.

Some useful links on Docker networking and Linux VLAN setup:

  • https://docs.docker.com/userguide/dockerlinks/
  • https://docs.docker.com/articles/networking/
  • https://github.com/jpetazzo/pipework

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: Installation

3.2.1. ION-DTN

Detailed steps on how to install ION can be found here but you need to adapt those instructions to work in a Docker image.

3.2.2. DTN2

Refer to the readme in the DTN2 distribution for installation instructions.

3.2.3. IBR

You will find a step-by-step installation tutorial here.

 

 

3.3. Challenge Task: Tests

3.3.1. Installation Tests

After you have successfully installed each of the 3 DTN distributions in a separate Docker image, execute docker run to start each tool on port 4556, then from your host machine running the docker daemon, use the telnet tool to establish a network connection (i.e. telnet docker-node-name 4556) to demonstrate that each DTN distribution has been installed correctly.

3.3.2. Network Tests

In addition to the installation tests above, reviewers will use your Docker setup instructions to set up a multiple node network to see if inter-container communication has been set up correctly.

The approach of this test is to use the IPND neighbor discovery protocol. The IPND protocol allows a local network node to know if nearby nodes on the same network are online or offline and it works independently of the DTN distribution that is installed in each container.

Test Scenario

The test will be setup as follows:

If node 1, node 2 and node 3 constitute a 3-node local network (each running in its own Docker container), each node should be able to learn of the existence of at most 1 other node via the IPND protocol. 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 ION-DTN on port 4556. (Note that because ION-DTN does not yet support IPND, it should not be discovered as being online by node 1 and node 2. In addition, node 3 should not know of the existence of node 1 and node 2. This challenge is part of a larger project that will build and add IPND support to ION-DTN.)

 

4.0. Challenge Deliverables

Please submit, in a compressed archive:

  • Deployment Guide (DG): describing how to deploy and test your Docker image;
  • Code: any scripts used to automate the deployment process must be written in Python.

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.

ELIGIBLE EVENTS:

2015 topcoder Open

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30049594