DINET Deep Impact Network Experiment Adapted from Technical

DINET Deep Impact Network Experiment Adapted from Technical Summary, Management and Project Engineering DINET CDR 6/2/08 Ross Jones 5/22/2008 1

DINET Summary • • DINET is a technology validation experiment of JPL’s implementation of Delay-Tolerant Networking protocols. The DINET development is to produce a version of JPL’s implementation of Delay-Tolerant Networking protocols in flight and ground SW at TRL 8. – • • The DINET SW is to be of sufficient quality that future flight projects can easily use it at low risk. DINET is to be implemented on the Deep Impact spacecraft and is being closely coordinated with the EPOXI project. DINET operations will be performed during the Deep Impact spacecraft team “stand down” after EPOCH operations and before the start of development for DIXI operations, i. e. Oct, 2008 – DINET requires no trajectory change. DINET developments and operations will be on a non-interference basis with EPOXI to the maximum extent possible. Note: DINET data traffic will be AMS messages containing small images. 5/22/2008 2

Basic Experiment Network Topology Earth Orbiter Relay Mars (surface asset) 5/22/2008 (DI s/c acts as orbiter relay) Phobos (surface asset) 3

Experiment 1: Send images from nodes 12 to node 8 via nodes 6, 3, 7 (the Deep Impact spacecraft), 2, 4. Also send images from nodes 20 to node 8 via nodes 10, 5, 7 (the Deep Impact spacecraft), 2, 4. Deep Impact DSOT DINET EOC in PTL NOTE: Deep Impact science spacecraft is functioning as a router (infrastructure). EVRs Experiment database Load/Go 16 stot “Earth” 2 client server 4 8 3 7 client server 6 12 “Mars” image files 5 bundles log msgs 5/22/2008 space links TCP BRS LTP/UDP client server 10 20 “Phobos” image files 4

Experiment 2: Send Load/Go directive loads from node 16 to node 12 via nodes 4, 2, 7, 3, 6. Also from 16 to 20 via 4, 2, 7, 5, 10. Deep Impact EVRs DSOT DINET EOC in PTL Experiment database Load/Go 16 stot “Earth” 2 client server 4 8 3 7 client server 6 12 “Mars” image files 5 bundles log msgs 5/22/2008 space links TCP BRS LTP/UDP client server 10 20 “Phobos” image files 5

Experiment 3: Omit a contact between 7 and 5 and repeat, forcing images from 20 to travel via 10, 6, 3, 7, 2, 4 and forcing directive loads to 20 to travel via 4, 2, 7, 3, 6, 10. Deep Impact EVRs DSOT DINET EOC in PTL Experiment database Load/Go 16 stot “Earth” 2 client server 4 8 3 7 client server 6 12 “Mars” image files X NOTE: spacecraft is temporarily unable to function as a router. 5 bundles log msgs 5/22/2008 space links TCP BRS LTP/UDP client server 10 20 “Phobos” image files 6

Experiment 4: manually route traffic between nodes 12 and 20 (both remote) via the orbiter, without Earth in the loop from node 20 to 12 and 12 to 20. Deep Impact EVRs DSOT DINET EOC in PTL Experiment database Load/Go 16 stot “Earth” 2 client server 4 8 3 7 client server 6 12 “Mars” image files 5 bundles log msgs 5/22/2008 space links TCP BRS LTP/UDP client server 10 20 “Phobos” image files 7

The DINET Stack Image publisher/receiver AMS messaging load/go Remote AMS compression BP DTN forwarding Convergence layer adapter LTP CFDP File Data PDUs (“Protocol X”) UT adapter rfx, admin programs, clocks space packets TM/TC R/F, optical 5/22/2008 8

Interplanetary Overlay Network (ION) • Reference implementation for the DTN Bundle Protocol (BP) is DTN 2, maintained at UC Berkeley. – Designed as a research vehicle. – Widely used, well supported. • Most DTN researchers are investigating terrestrial applications, for which DTN 2 works very well. • Space flight applications impose different constraints, motivating development of an alternative BP implementation for use in space flight missions. • ION is an implementation of BP/LTP, developed at JPL, that’s designed to be usable in flight. 5/22/2008 9

Constraints on a Flight Implementation • Link constraints – All communications are wireless, generally slow, asymmetric. • From spacecraft to ground: 256 Kbps to 6 Mbps. • From ground to spacecraft: 1 to 2 Kbps. – Links are very expensive, virtually always oversubscribed. – Fine-grained data delivery. • Immediate delivery of partial data is often OK. • Processor constraints – Flight processors typically run real-time operating systems (Vx. Works®, RTEMS™) lacking protected memory models. – Robustness is paramount. No malloc and free or standard new and delete; must not crash other flight software. – Processing efficiency is important: • Slow (radiation-hardened) processors. • Relatively slow non-volatile storage: flash memory. 5/22/2008 10

ION’s Divergence From DTN 2 Design Element DTN 2 ION Rationale Language C++ C Processing efficiency, memory management visibility. Memory management new, delete PSM No dynamic system memory management permitted. Non-volatile storage management Berkeley DB, RDBMS (My. SQL) SDR persistent objects Processing efficiency, footprint. Locus of processing dtnd daemon process, separate routing engine highly distributed: forwarders, ducts, applications, and admin tools Robustness (module simplicity, incremental upgrade; prevent headof-line blocking); simplify flow control. Locus of node state (e. g. , queues) private memory of dtnd daemon shared memory Support distributed functionality, limit impact of demand spikes. Application Programming Interface remote procedure calls to dtnd shared library functions act on shared memory Support real-time operations: prevent blocking, support deterministic execution. Endpoint IDs in bundle’s primary block only ASCII URIs in dictionary supports CBHE Bandwidth efficiency. 5/22/2008 11

Performance ION flight software footprint: about 708 kilobytes including SDR database management system. 5/22/2008 12

Contact Graph Routing #*************************************** # # ** DINET experiment pass #1. Monday morning, October 20. ** # @ 2008/10/20 -11: 00 a range +0 +14400 2 7 79 a range +0 +14400 3 7 79 a range +0 +14400 5 7 79 # # Contact between nodes 5 and 7 for 60 min. @ +0 a contact +0 +3600 5 7 250 a contact +0 +3600 7 5 20000 # # Contact between nodes 3 and 7 for 120 min. @ +3900 a contact +0 +7200 3 7 250 a contact +0 +7200 7 3 20000 # # Contact between nodes 2 and 7 for 50 min. @ +7500 a contact +0 +3000 2 7 250 a contact +0 +3000 7 2 20000 # 5/22/2008 13

Status of ION • Conforms to version 6 of the BP specification (June 2007). • Single code base runs without modification in all environments. So far: – – Red Hat Linux 8+, Ubuntu Linux on 32 -bit processors. Fedora Core 3+, on 32 -bit and 64 -bit processors. Vx. Works 5. 4 on Power. PC 750. Mac OS/X • Interoperability with DTN 2 (and other Bundle Protocol implementations: C#, . Net, Symbian) demonstrated at IETF in San Diego, November 2006. 5/22/2008 14

DINET Instrumentation • Protocol status, diagnostic, and statistics messages issued by every node, including the spacecraft. • Current network topology and running logs of messages displayed on the operations console in the Experiment Operations Center. • Detailed “watch” character stream of event indications can be selectively enabled and disabled in real time at each node. 5/22/2008 15

Key Metrics • • Metric 1 – Link Utilization Rate Metric 2 – Delivery Acceleration ratio Metric 3 – ION Node Storage Utilization Metric 4 – Multipath Advantage Applicability to DTN Features Link Utilization • • • 5/22/2008 Priority Dynamic Routing Automated Forwarding Custody Transfer Delay-Tolerant Retransmission Flow & Congestion Control Delivery Acceleration Ratio ION Node Storage Utilization Multipath Advantage X X X X 16

DTN Validation Criteria • Metric 1 – Path utilization rate (U) – U = RT/K, where RT is total volume of science data returned and K is the total data return capacity (adjusted per artificially induced segment loss as applicable). – Measures the effectiveness of automatic forwarding, custody transfer, and delaytolerant retransmission. – Validation criteria: • Ua > 90%. (DTN uses the links efficiently when there is no induced data loss. ) • Ub > 90%. (DTN remains efficient despite an increase in the rate of data loss. ) • 5/22/2008 Metric 2 – Delivery acceleration ratio (G) – W = (. 5 *) + (1. 0 * R 1) + (2. 0 * R 2), where W is the urgency-weighted volume of science data returned and R 0, R 1, and R 2 are respectively the total volumes of priority-zero, priority-1, and priority-2 science data returned. (Note that R T = R 0 + R 1 + R 2. ) – Q 0 =. 25 * RT where Q 0 is the “reference” volume of priority-zero science data returned, so computed because we will arbitrarily assign priority zero to 25% of all DINET science data. • Similarly, Q 1 =. 60 * RT and Q 2 =. 15 * RT. – V = (. 5 * Q 0) + (1. 0 * Q 1) + (2. 0 * Q 2), where W is the urgency-weighted reference volume of science data returned. – G = W / V. – Measures the effectiveness of the priority system. – Validation criteria: • Ga > 1. (Prioritization accelerates the delivery of urgent data. ) • Gb > 1. 17

DTN Validation Criteria (Continued) • Metric 3 – ION node storage utilization – Retention of a stable margin of unassigned space at each node measures the effectiveness of congestion control. – Validation criteria: • The total number of bundles for which custody is refused anywhere in the network for the reason Depleted Storage, throughout each experiment, is always zero. (Never run out of storage anywhere. ) • NX 4 = NX 3 and NX 8 = NX 7 for all values of X. (Storage utilization stabilizes over the course of the experiment. ) • Metric 4 – Multipath advantage – The net path capacity PXYa for any single path from node X to node Y during configuration a is the smallest value of ∑KABZ for Z = 1 4 among all links (A, B) in that path; PXYb is similarly defined for configuration b. – The multipath advantage MXYa for traffic from X to Y during configuration a is computed as ∑PXYa for all paths from X to Y, divided by the largest single PXYa among all paths from X to Y, minus 1. – Where there is only a single possible path between X and Y, multipath advantage is zero. Multipath advantage measures the effectiveness of dynamic routing. – Validation criteria: • • 5/22/2008 MXYa > 0 for X = node 20 and Y = node 8. (Dynamic routing among multiple possible paths increases the total network capacity from Phobos to Earth. ) MXYb > 0 for X = node 20 and Y = node 8. . 18

Environment Envelope • • Given or measured quantities that will be reported as part of the experiment These are the primary mission parameters and initial conditions that affect the performance results for a given DTN implementation. • Environment Envelope – – – 5/22/2008 – Propagation Delay - 2 min Partition Delay - 5 day (contact latency - network is partitioned) File Size - Range is 2 -65 KB • Maximum size message with AMS is 65 KB • For images larger than 65 KB, a mission should use CFDP in conjunction with AMS and BP but this is not part of our experiment since simple unacknowledged CFDP has been implemented previously. Data Rates (128 -400, 000 bps) Number of end nodes (11) Number of links per node total number of links Contact duration (4 hours) Data volume Data Completeness Data Quality Bit Error Rate Available buffer size 19

DTN Protocol Envelope 5/22/2008 20

Project schedule • • 5/22/2008 Critical path runs through the ION/DIAS testing on EPOXI test beds There are 17 days of funded project schedule reserve 21