DRAFT / OUTLINEDRAFT / OUTLINEDRAFT / OUTLINE

DTN Concept Paper [DRAFT OUTLINE]

(CCSDS White Book)

March 4, 2008

Introduction

Space communications is moving from ‘link-centric’ to ‘network-centric’ approach.

NASA Constellation and MERs as examples.

ESA Aurora / Odyssey as examples.

Terrestrial networking protocols assume things that do not necessarily hold in space communications.

Delays.

Disruptions / lack of contemporaneous end-to-end path.

This concept paper describes the motivation for the development of a DTN overlay network architecture to address the delays and disruptions inherent in space communications. This paper proposes that CCSDS assess the applicability of the Bundle Protocol as specified in IETF RFC 5050 as a DTN protocol to address the space communications environment. Where RFC5050 and associated RFCs / Internet Drafts are deemed insufficient, we propose CCSDS examine the feasibility of extending them in a standardized and compatible way.

Motivation

Examples from MER/[Odyssey/Mars Express]. Talk about the lack of end-to-end path in the space environment and why. What this does to terrestrial IP stack. Emphasize that IP as an addressing mechanism works just fine, it’s things like router implementations, interactive sub-protocols like DNS, temporal associations like DHCP leases, etc. that are bothersome.

Delay / Disruption Tolerant Networking (DTN)

DTN history and family tree information. Started out funded as work primarily to address NASA space communication need and funded through DARPA / NASA. Mention demos at JPL in 200X. Exposed to wider community including sensor networks. Funding picked up by DARPA for DoD applications but with strong desire for open standard and extensibility. Same implementation choices that make DTN extensible for DoD-specific missions make it extensible for space-specific ones (not really a protocol issue, but maybe one of those ‘cost-of-ownership’ things).

DTN Architecture and Bundle Protocol

The DTN architecture document (RFC4838) and bundle protocol document (RFC5050). Briefly describe capabilities, etc. These should be considered as a starting point for CCSDS standardization.

CCSDS-Specific Activities

This section describes proposed activities of the working group to determine if RFC5050 is in fact applicable and what modifications might be needed for space missions.

Mission Model

Identify or generate a high-level model for a number of mission types (LEO, Lunar, Mars, Deep-Space). For example, the Mars mission model might include NASA and ESA orbiters, and NASA and ESA landed elements. This is not meant to be exclusive, and could easily include elements from other agencies. This activity is NOT a long-term item and is intended to help identify any space-specific protocol requirements and to evaluate proposed solutions.

Evaluate Applicability of RFC5050

Assess applicability of IETF-defined DTN protocol (RFC5050) for space. Assess extensibility of the protocol to space-specific environments and identify deficiencies. Determine if the protocol is sufficiently flexible / extensible to meet the space requirements in a standardized and compatible way. Examine the applicability of various implementations of RFC5050 (DTN2, ION, CBHE extension, …?)

An initial list of proposed requirements is:

  • Works in long haul (scheduled) and terrestrial (opportunistic) environments.
  • Reliability separate from security.
  • Works for long delays and short disruptions.
  • Has routing and application development as part of the DTN suite to make this usable over a wide variety of environments. Develop routing protocols that are relevant to space-base deployments.
  • Easy to deploy
  • Deployable security
  • Does not require fine-grained network synchronization (Decrement time to live to prevent route loops and eternal bundle propagation)
  • Associated transport mechanisms should be easy to deploy and any tuning mechanisms should be well documented and concise (i.e. practical to deploy).
  • Interoperable with international terrestrial COTS standards

Evaluate Applicability of Licklider Transport Protocol

RFC5050 requires a reliable hop-by-hop delivery service between overlay routers. While CCSDS has reliable data link protocols in both TC and AOS, additional capabilities are required by convergence layers underneath the RFC5050 definition of DTN. It is likely that any Delay Tolerant Networking protocol proposed by this group (even if not based on RFC5050) will also need reliability on a hop-by-hop basis. Thus this working group will also standardize a reliable hop-by-hop data delivery protocol that can be used by the Delay Tolerant Networking protocol specified by this WG. The Licklider Transport Protocol (LTP) as described in the work-in-progress was designed for exactly this purpose, and will be the initial focus of this part of the WG effort.

Identify Transition Plan

Identify transition plan from current operations through DTN deployment. Because DTN can and probably should run over space packets, there will be the opportunity to run both ‘traditional’ space packet-based and DTN-based data streams in parallel. As missions become comfortable with DTN services, DTN will hopefully supplant other packet-relay mechanisms to become the standard for data relay in space.

Identify Cross-Support Points

In space, the cross support point will probably be DTN over space packets for cross support between (e.g.) landed elements and orbiters. Missions that use only space packets will still be able to be cross-supported at the packet level, but will have to rely on non-DTN mechanisms for packet forwarding (e.g. the way the NASA MERs operate now). On Earth, two possible cross-support points include space packets over CSTS and ‘direct’ DTN bundles over some Internet transport layer.

References

DTN Architecture Document (RFC4838)

DTN Bundle Protocol Specification (RFC5050)

Licklider transport protocol (draft-irtf-dtnrg-ltp-09.txt)

Draft outline in advance of Spring 2008 CCSDS meetings. Last updated 20080212