Name of Group | 6.09 Delay Tolerant Networking Working Group |
Area | Space Internetworking Services Area (SIS) |
Chairperson | Robert Durst |
Chairperson E-Mail Address | durst@mitre.org |
Chairperson Agency | NASA |
Deputy Chairperson | Kiyohisa Suzuki |
Deputy Chairperson E-Mail Address | suzuki.kiyohisa@jaxa.jp |
Deputy Chairperson Agency | JAXA |
Mailing List | sis-dtn@mailman.ccsds.org |
Scope of Activity | Standardization of a space internetworking protocol capable of operating in environments with large and/or highly varying delays and disruptions caused by planned or unplanned link unavailability. Disruptions may partition the network so that there may be significant times when no end-to-end path exists. The internetworking protocol definition may include support for quality of service and streaming delivery mechanisms.
Standardization of supporting protocols and conventions such as link-layer reliability protocols, routing protocols, network management, a unified naming scheme, etc. In particular the network management work (here 'network' is interpreted as the internetworking layer and not NASA's interpretation of e.g. the DSN, NEN, etc.) will interact with other cross-support activities. Where appropriate the WG will work with the Cross Support Services Area to ensure a coherent system and to avoid duplication of effort.
|
Rationale for Activity | 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.
|
Goals | 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.
|
Survey of Similar Standards Efforts Undertaken in Other Bodies and elsewhere in CCSDS | 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. |
Patent Licensing Applicability for Future Standards | There is a US Patent "US 7,930,379 B2" http://www.freepatentsonline.com/7930379.html that MAY be applicable to the Bundle Protocol. |
Technical Risk Mitigation Strategy | 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.
|
Management Risk Mitigation Strategy | Unavailability of resources could delay achievement of milestones. Fallback option would be to reschedule the milestones. |