Charters : 6.09 Delay Tolerant Networking Working Group

 

Historically, lunar and planetary exploration spacecraft have been few in number and have communicated only with operations centers on Earth.  Such communications have in effect been dedicated interplanetary communication circuits, established and configured by human operators.  Recent experiences at Mars have shown that using orbiters to relay data from the surface can greatly increase science data return; similar benefits are expected in other locales such as around the moon.  International cross-support for this relaying capability will increase mission robustness and science data return, allowing surface elements multiple opportunities to forward data to Earth.  As the number of relays and relay users increases, the need to automate a standard data relay service will increase.

The familiar Internet network protocol model is not equal to this task, as it is not designed for effective operations over communication links characterized by very long signal propagation latencies, frequent and prolonged service interruptions, and limited and highly asymmetrical transmission rates.  Something new will be needed.

In short, communication with and among a large and growing population of communicating entities (robotic sensors, for example) separated from Earth by interplanetary distances and/or by recurring lapses in mutual visibility due to orbital or planetary motion will require deployment of a store-and-forward communication network that is capable of providing reliable data delivery and dynamic routing in a fully automated fashion.

DTN-WG is a Standards Track Working Group.  The Working Group will determine whether or not “Delay-Tolerant Networking” as specified in RFC5050 is a feasible solution for a store-and-forward networking protocol for space environments where data relay is likely.

If RFC5050 is deemed suitable overall but lacking in certain specific capabilities needed by the space community, this working group may define extensions to RFC5050 to address these needs.  If RFC5050 is not suitable, the WG will attempt to define an alternate protocol that meets the needs of the space community.

RFC5050 requires a reliable data delivery service between overlay routers.  While CCSDS has reliable data link protocols in TC and AOS, neither is well-suited for use as a convergence layer by RFC5050.  It is likely that any Delay Tolerant Networking protocol proposed by this group will need reliability on a hop-by-hop basis.  Thus this working group will also standardize a reliable hop-by-hop data delivery service 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 http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt was designed for exactly this purpose, and will be the initial focus of this part of the WG effort.

The WG will also develop a Pink Sheet for CFDP to specify additional mechanisms to be used when CFDP is used over BP (allow an acknowledgement that the file has been delivered when CFDP is used in unreliable mode).

This working group will also develop the Solar System Internetworking Architecture Document in response to the IOAG request to CCSDS.  This document will be targeted as a Green or Magenta (under the proposed modified procedures) book.

The working group will develop a Green and a Blue Book related to network management of BP-based networks.  The books will define the concepts (Green book) and protocols to effect network management of DTN networks.

Finally, the group will develop a Blue Book to standardize Quality of Service mechanisms and behaviors for CCSDS BP networks.

Per standard CCSDS procedure, development of this Recommended Practice will entail demonstration of mission operations in a prototypical DTN-based network environment.

See Technical Risk Mitigation Strategy below.  Work on Delay / Disruption Tolerant Networking has been ongoing in the Internet Research Task Force (IRTF) and experimental protocols have been defined.

There is a US Patent "US 7,930,379 B2" http://www.freepatentsonline.com/7930379.html that MAY be applicable to the Bundle Protocol.

It is believed that the DTN architecture and the DTN protocol as defined by the IETF are generally suitable for the CCSDS community.  Where space-specific capabilities are needed, we believe that extensions to the base DTN protocol will be able to address the required functionalities.  If the base DTN protocol as specified by the IETF is found to be unsuitable for space missions, development of a completely new protocol could be required and the schedule would slip, probably by a year.

A stable implementation (believed to be suitable for space mission operations) of a previous version of the DTN specifications exists.  Slight modification of this version should bring it in line with the specification of RFC5050.  Multiple other implementations of the DTN protocol exist, most not suitable for space mission operations.  Resources have been identified to develop a second “space-qualifiable” DTN implementation if such is required.  These facts argue that there is little technical risk in generating two interoperable implementations, provided that the protocol in RFC5050 is basically suitable.

Similarly, the LTP protocol described in http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt was designed specifically to be a reliable hop-by-hop transfer service for long-haul space links.  As such, it should fulfill the requirements of the upper-layer DTN protocols.  There is at least one LTP implementation that was designed for use on space missions.  As part of the work program for recommending a reliable hop-by-hop delivery protocol, another implementation may need to be developed.  Because there are multiple LTP implementations (though not necessarily designed for space mission operations), this should be a low-risk activity.

Unavailability of resources could delay achievement of milestones.  Fallback option would be to reschedule the milestones.