SIS Deep Space Protocols Status

1. SIS Deep SpaceProtocols Status Scott Burleigh, JPL

2. Overview • CCSDS File Delivery Protocol (CFDP) • Unacknowledged CFDP Extensions (UCE) pink sheets were issued for review and agency approval on 19 October 2004. • Max Ciccone will report on progress in interoperability testing. • Delay-tolerant networking (DTN) • BOF meets for the first time in November of 2004. • Licklider Transmission Protocol (LTP) • A link-neutral point-to-point retransmission system designed to support DTN operations in deep space. • BOF will be proposed later this week. • Asynchronous Message Service (AMS) • A companion protocol to CFDP, for message exchange over the deep space delay-tolerant network. • BOF will be proposed later this week.

3. CFDP UCE (1 of 2) • Motivated by processing requirements for Mars Reconnaissance Orbiter (MRO): MRO wants to run CFPD in unacknowledged mode over a reliable UT layer, in this case a non-standard AOS frame retransmission system. • Problem: • Version B2 of CFDP closes an unacknowledged-mode transaction as soon as the EOF PDU is received. • But a reliable UT layer might cause missing file data PDUs to be retransmitted after EOF receipt. Because the transaction is closed, these PDUs would never be collected into the delivered file. • Solution: add a “check timer” that works in unacknowledged mode the same way the NAK timer works in acknowledged mode. Transaction is closed only when examination finds that reception is complete – either on EOF arrival or on check timer expiration – or when check timer expiration limit is reached.

4. CFDP UCE (2 of 2) • Status: • BOF formed in May of 2003 and agreed on design. • Working group approved in October of 2003. • Implementation demonstrated in February of 2004. • Initial pink sheets completed in March of 2004. • Revised pink sheets completed in May of 2004. • Pink sheets issued for agency review and approval on 19 October 2004.

5. 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

6. 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.

7. 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.

8. 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.

9. Network Deployment

10. 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.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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

16. 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.

17. Asynchronous Message Service (1 of 3) • In addition to file transfer, event-driven asynchronous message exchange may also be useful for deep space communications with and among spacecraft : • streaming engineering (housekeeping) data • real-time commanding • continuous collaborative operation among robotic craft • NASA’s proposed new Command, Control, Communications, and Information (C3I) architecture is based on this model. • Challenges in large-scale asynchronous message exchange: • Heterogeneity: platforms, security regimes, communication environments, QOS requirements, performance requirements, cost tolerance. • Changing topology: requires autonomous discovery of communication endpoints, automatic reconfiguration. • Publish/subscribe message exchange model scales better than client/server.

18. Asynchronous Message Service (2 of 3) • But most asynchronous message exchange systems are: • proprietary, licensed products (e.g., TIBCO Rendezvous, NDDS) rather than open international standards; • not designed for operation on deep space robots. • Proposed CCSDS Asynchronous Message Service (AMS) standard is based on proven NASA technology: no commercial licensing, designed for spacecraft flight operations. • Tramel (Task Remote Asynchronous Message Exchange Layer) was developed in JPL’s Flight Systems Testbed (FST) in 1995-1996; mature and stable since 1998. • Real-time spacecraft simulation in FST (1994-1999). • Software fault tolerance experiments at JPL (1998). • X-34 Integrated Vehicle Health Management testbed (2003). • Baselined for inclusion in C3I.

19. Asynchronous Message Service (3 of 3) • AMS features: • Platform-neutral, UT-layer neutral. • Designed to scale from very small to very large configurations. • Self-configuring and fault-tolerant, via silent “meta-AMS” protocol. • “Remote AMS” adaptations enable efficient, delay-tolerant publish/subscribe capability over interplanetary distances. • Status: • Concept paper (tentative protocol specification) ready for review. • Fully-functional, well-documented prototype (Tramel) has been mature for six years.

20. Deep Space Communications Architecture User application AMS CFDP file system functions 7 CFDP unacknowledged transmission (no retransmission, no store-and-forward) UT adapter 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