Delay-Tolerant Networking (DTN) General-purpose capability for scalable, reliable communications across deep space. Extending and streamlining the capabilities of CFDP: Built-in security (authentication and confidentiality). Flexible, dynamic multipath route selection. Deferred transmission, store-and-forward routing for tolerance of intermittent connectivity. Point-to-point retransmission for efficient reliability. Custody transfer for early release of retransmission resources. Will enable CFDP to scale up to large deployment configurations. Bundling store-and-forward LTP point-to-point retransmission TCP “point-to-point” retransmission IP TM TC AOS Prox-1 Ethernet R/F, optical wire

CFDP Basic Deployment Premise: entities can communicate directly (R/F or optical). Mutual line-of-sight visibility. Compatible operating schedules: entity A can point at entity B and transmit at a time when entity B can point at entity A and receive. Adequate links: the levels of transmitter power and receiver power combine to produce a data rate greater than zero. Implementation: core CFDP over CCSDS TM/TC (or AOS) UT layer.

CFDP Advanced Deployment Premise: entities cannot communicate directly. No mutual visibility: intervening planetary mass, intervening Sun. Incompatible operating schedules. Insufficient signal power between sender and receiver. So CFDP must support indirect communication, via “relay” or “waypoint” entities, using store-and-forward techniques. Constraint: a single, serial end-to-end route from the sender to the receiver for the duration of each transaction. Implementation options: Extended procedures Additional functionality built into CFDP itself. Store-and-forward Overlay CFDP is left unchanged. Additional functionality built into standard user application layer.

CFDP Network Deployment Premise: As in Advanced Deployment, entities cannot communicate directly. But the constraint on Advanced Deployment is removed: multiple forwarders may operate in parallel for a single CFDP transaction. So data may routinely arrive out of transmission order. Bad for end-to-end acknowledged CFDP: whenever EOF arrives before file data segments, unnecessary retransmission is triggered. Implementation: core unacknowledged CFDP over Delay-Tolerant Networking (DTN) bundling protocol. Standard class-1 CFDP over reliable Bundling UT layer.

Bundling As in the Internet, there may be multiple possible routes (both in space and time) to the destination. Multi-layer routing: End-to-end routes are computed by “bundling” protocol. Route to next hop within the same region – if not point-to-point – is performed by region-specific protocol, such as IP within the Internet. Internal routing technology can be different in different regions. Tuned for cost effectiveness. Evolving independently. This enables end-to-end routing complexity to scale up indefinitely without imposing excessive overhead within any single region.

Bundling (cont’d) Bundle forwarding algorithms may consider: requested delivery deadline estimated time to destination on alternative paths class of service, e.g., explicit transfer of custody For example, bundling might withhold bundles from an impending low-rate contact in favor of a future high-rate contact. Routing decisions are re-evaluated at each forwarding hop. Nature of connectivity may affect routing decisions: continuous opportunistic scheduled Schedules loaded via management interface or routing protocol.

Bundling (cont’d) Additional features: “Reply-to” address may differ from original source. Optional interim progress reports (similar to SFO). Optional end-to-end reception report, retransmission. Support for multiple user applications: CFDP sensor webs messaging Explicit transfer of custody. Not all forwarding nodes need be custodians.

LTP LTP is Licklider (or “Long-haul”) Transmission Protocol. Directly descended from CFDP Core reliability procedures, with a few simplifications: It’s not file-oriented. LTP divides a block into segments for reliable transmission. No filestore commands, no metadata. (File-oriented mechanisms are left to CFDP, above bundling.) Indications analogous to EOF, Finished, Prompt, etc. are combinations of bit flags in the standard header. The last segment of a block carries an “end of block” flag. There’s no separate “EOF” segment, so a small block may be entirely contained in a single segment. Negative acknowledgment segments are sent reliably, so there’s nothing like the NAK timer cycle. All timeout intervals can be computed from operational data: no guesswork. No transaction-specific Suspend and Resume, no flow labels.

LTP (continued) What’s retained from CFDP core reliability procedures: Deferred transmission. Parallel transactions, with a transaction cancellation mechanism. Negative acknowledgment of missing data, positive acknowledgment of critical (e.g., end of block) segments. Abstract interface to underlying transmission layer. Simple analogs to the Prompt and Keepalive mechanisms. All four “lost segment detection” options: deferred, prompted, immediate, asynchronous. Link-specific Freeze and Thaw.

CFDP/DTN Architecture User application CFDP file system functions CFDP unacknowledged transmission 7 (no retransmission, no store-and-forward) UT adapter Bundling store-and-forward (bandwidth management) TCP end-to-end retransmission 4 IP network routing 3 “UT layer” LTP point-to-point retransmission COP/P retransmission 2 TM/TC, AOS Prox-1 Ethernet R/F, optical wire 1

DTN Status Spring of 2002: Internet Research Task Force research group DTNRG formed to articulate DTN concepts. Summer of 2002: first demonstration of initial Bundling implementation. March 2003: peer review of DTN architecture Internet Draft. May 2004: DARPA issues BAA (Broad Agency Announcement) for its DTN research program. July 2004: version 01 of LTP Internet Draft published. Version 02 editing is in progress. Stephen Farrell is working on the first implementation. September 2004: version 03 of Bundling protocol spec Internet Draft published. November 2004: initial meeting of CCSDS DTN BOF.