Name of Group
Short Name
Chairperson E-Mail Address
Chairperson Agency
Deputy Chairperson
Deputy Chairperson E-Mail Address
Deputy Chairperson Agency
Mailing List
Scope of Activity
Rationale for Activity
Survey of Similar Standards Efforts Undertaken in Other Bodies and elsewhere in CCSDS
Patent Licensing Applicability for Future Standards
Technical Risk Mitigation Strategy
Management Risk Mitigation Strategy
Description of Change
CCSDS Tech Support (5/29/2012 1:07 PM): Note patent US 7,930,379 B2
CCSDS Tech Support (7/22/2011 1:16 PM): Add work items for: Pink Sheet to CFDP for use over BP ; SSI Architecture document (Green Book); BP Network Management (Green Book, Blue Book); Quality of Service for BP (Blue Book)
Scott Keith (5/25/2011 6:03 AM): Add work items for: <br />
Pink Sheet to CFDP for use over BP <br />
SSI Architecture document (Green Book) <br />
BP Network Management (Green Book, Blue Book) <br />
Quality of Service for BP (Blue Book)
Scott Keith (5/25/2011 6:01 AM): Add work items for:
    <li>Pink Sheet to CFDP for use over BP</li>
    <li>SSI Architecture document (Green Book)</li>
    <li>BP Network Management (Green Book, Blue Book)</li>
    <li>Quality of Service for BP (Blue Book)</li>
Disable Alert
Area Director E-Mail Address
Deputy Area Director E-Mail Address
Create Poll
CC Yourself
Approval Status

Name of Group

6.09 Delay Tolerant Networking Working Group


Space Internetworking Services Area (SIS)


Keith Scott

Chairperson E-Mail Address

Chairperson Agency


Deputy Chairperson

Kiyohisa Suzuki

Deputy Chairperson E-Mail Address

Deputy Chairperson Agency


Mailing List

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.


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 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" 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 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.
Created at by
Last modified at by

Note - To view "Draft" projects, which are not yet approved Click Here.

 Approved Projects

|Export to Spreadsheet|
Currently 9 Projects     
Document Type
Project Status
Project Phase
Modified By
CCSDS Bundle Protocol Network ManagementGreenBehind ScheduleFirst draft comments dueBrian Oliver 
CCSDS Bundle Protocol Network ManagementBlueBehind ScheduleFirst draft comments dueBrian Oliver 
Rationale, Scenarios, and Requirements for DTN in SpaceGreenAll Tasks CompletedProject CompletedCCSDS Tech Support 
Bundle Protocol for CCSDS (was DTN Protocol)BlueAll Tasks CompletedProject CompletedPeccia Nestor 
Licklider Transmission Protocol for CCSDSBlueAll Tasks CompletedProject CompletedPeccia Nestor 
Solar System Internetwork Architecture DocumentGreenAll Tasks CompletedProject CompletedCCSDS Tech Support 
BP Network ManagementBlueAll Tasks CompletedProject CompletedCCSDS Tech Support 
Schedule-Aware Bundle Routing (was Contact Graph Routing) for CCSDSBlueAll Tasks CompletedProject CompletedBrian Oliver 
Bundle Security Protocol for CCSDSBlueOn ScheduleSecretariat Document Processing 2Brian Oliver