Challenge Overview

Overall Requirements

The objective of the NASA DTN Project is to develop an overall set of data communications protocols and associated deployment infrastructure to enable space agencies to incrementally build up a Solar System Internetwork (SSI).  The NASA Space DTN Project will develop and mature the necessary and generic DTN technology for use on a wide range of human and robotic space missions that will be part of the SSI.

The DTN protocol suite can run over the existing Internet Protocol (IP) suite or it can operate by itself as a full Internetworking protocol. DTN provides assured delivery of data using an automatic store-and-forward mechanism, while IP generally does not.

NASA needs to integrate the ION Disruption Tolerant Networking (DTN) implementation of Bundle Protocol (BP) with Microsoft Outlook and Microsoft Exchange Server to support the transfer of astronaut email to/from the International Space Station (ISS).

High-level architecture

Two permanent DTN gateways will be available on ISS to support mission operations and payload users and the corresponding ground gateways will also be put in place.

The gateways are the nodes that all DTN traffic will hit before being transferred over the space-to-ground link. The network setup can be thought of as: [Exchange Server] ⇔ [Ground DTN Gateway] ⇔ [Space DTN Gateway] ⇔ [Microsoft Outlook Client].

The space DTN gateway will be a Linux server running ION with network access to the ISS laptops running Microsoft Outlook. ION, the same code available via the SourceForge link, can be installed on Windows, so no custom DTN client development should be necessary. The package includes a file called winion.pdf that describes how to install ION in Windows with MinGW.  ION will be installed on the ISS laptops to support file transfers, so there will be access to the ION Windows service, including API calls that the developers can use to integrate with Outlook.

NASA needs a plug-in/extension for Outlook/Exchange Server that converts the TCP-based protocols used by Outlook (on-board the ISS) to communicate with an Exchange server (on Earth) to instead use the DTN Bundle Protocol (BP). If a plug-in is not feasible, then any other type of mechanism or gateway application is sufficient.

Detailed Requirements

The DTN support code will need to satisfy the following requirements:

 

  • The solution must include both ends of the communication (client-side and server-side).
  • The DTN support code shall not cause interference with other ground users that are using the same Exchange server without DTN.
  • The solution must be able to support:
    • Unpredictable suspension of communication for up to 4 hours.
    • Unpredictable loss of data.
    • Round trip times on the order of .6 s – 1 s.
  • The DTN support code shall utilize the ION 3.2.0 API for all bundle transmission and reception.
  • The DTN support code shall support all traffic/functionality to/from Outlook/Exchange to use the DTN protocol, and if that is not feasible within the budget/timeline, we need to focus on email & calendar, and anything else will be considered a bonus. This must work in both directions (Outlook → Exchange and Exchange → Outlook).
  • The DTN support code shall interface with Microsoft Outlook/Exchange Server 2010 (only the 2010 version, and no others are required).
  • The DTN support code for Outlook 2010 shall operate on a computer running Windows 7.
  • The integration with Outlook and Exchange shall be configurable to use the ISS DTN assets that should be available in March 2015.
  • The DTN support code shall have the ability to turn the DTN functionality on/off as required.
  • Security is a concern for this project, and we will need to ensure that the final code has been tested for malicious code and vulnerabilities.

 

The DTN support code can assume and use all features of the BP for Consultative Committee for Space Data Systems (CCSDS) Protocol that is currently a draft specification within the CCSDS.  For instance, the DTN support code can assume that it can rely on the ‘custody transfer’ reliability mechanisms of BP, as well as features such as Delay Tolerant Payload Conditioning (DTPC) described in the draft specification.

Ideally the software solution would be provided as either an “add-in” or an extension to the existing Microsoft Outlook and Exchange Server software. If that is not achievable, then any other type of mechanism or gateway application is sufficient.

NASA provided configuration files for a sample setup which would use BP/TCP to communicate between a ground client and the ground DTN gateway and between the space client the space DTN gateway. The final architecture can use this configuration or provide a different solution. The communication between the space DTN gateway and the ground DTN gateway must be based on BP over LTP protocol. The picture bellow illustrates the high-level data flow:

Astrounaut-email

It would be preferred if the gateways did not have to be modified (i.e. would just serve as a bundle router). Your solution may work without the presence of the gateways to function. Essentially we would have a DTN email solution that came in a client/server (Outlook/Exchange) pair. The current ISS architecture includes the gateways, but it may not be the case for future space vehicles. The more the solution is globally applicable the better.



Final Submission Guidelines

Submission Deliverables

Your System Architecture submission will contain a combination of the following documents:

  • Application Design Specification
  • Sequence Diagrams
  • Class Diagrams
  • Component Diagrams
  • Assembly Specification(s)

The architecture must identify where each module will be installed (ground gateway, space gateway, outlook client or at the exchange server). It needs to detail where ION-DTN software will be installed and what other software will be necessary.

Ideally, the architecture will divide the assemblies considering the multi-layer development, for example: Outlook add-in, Exchange server extension, ground and space gateway setup and configuration (or any other needed development). This will allow running future assemblies in parallel.

Project Resources

Reference documentation. You have the bundle protocol specification as well as the link to download and setup the tools, if needed:

 

Final Submission Guidelines

Submissions must adhere to the following 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:

2014 TopCoder(R) Open

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30041729