Disruption Tolerant Networking DTN An Architecture for Evolving

Disruption Tolerant Networking (DTN) An Architecture for Evolving Communications Leigh Torgerson Protocol Technology Lab Manager Communications Architectures & Research (332) Jet Propulsion Laboratory, California Institute of Technology ltorgerson@jpl. nasa. gov 818 -393 -0695 © 2019 California Institute of Technology. Government sponsorship acknowledged.

Presentation Topics: • Why a Space Networking Architecture? • DTN History and Technical Overview • NASA Baseline Interplanetary Overlay Network (ION) DTN Suite • Current NASA Infusion Activities • JPL 332 Protocol Technology Lab Space Networking Testbed and Infusion Support for JPL • Questions

Why Networking? • Primarily because ops team management of point-to-point links doesn’t scale to the future Solar System Internetworking envisioned by NASA / CCSDS! REF: “Operations Concept for a Solar System Internetwork”, Interagency Operations Advisory Group (IOAG), 15 Oct, 2010. https: //www. esa. int/Our_Activities/Preparing_for_the_Fu ture/Discovery_and_Preparation/Space_internet_to_enha nce_Earth_observation (15 Jan 2019)

Why Not Just Use Terrestrial Internet Protocols? Six Key Assumptions Internet Protocol Design: • Networks are Richly Connected • Networks have Short Delay • Data Links are Symmetric and Bidirectional • Links have Low Error Rates, and that loss is due to Congestion • Network Nodes are Trustworthy • Connections are END-TO-END

Network Characteristics We Face • Sparse network • Asymmetric; half-duplex or unidirectional links • Loss due to corruption, not congestion • Loss due to orbital geometry, antenna pointing errors, etc. • Inordinately long propagation times between nodes • Insecure – the threat: you don’t need a 34 m dish to hack lunar comm links for instance

Quick DTN Intro Video Please see You. Tube version https: //youtu. be/c_tc. C 51 PIu. M

Brief Historical Outline • The Beginning: 1998 – A few members of JPL Space Mission Operations Standardization Program met with Dr. Vint Cerf to explain our work on enabling FTP/TCP/IP/IPSEC to adequately perform over geostationary satellites hops. We knew that wouldn’t scale to interplanetary distances, and that more research was needed to really expand the internet into space. Vint arranged DARPA funding and became a member of the team to study how to extend the internet into the solar system.

1999: the IPN Architecture Core Team Bob Durst Howie Weiss • – Eric Travis Scott Burleigh Vint Cerf, Sr. Vice President of Internet Architecture, Worldcom Inc. and JPL Distinguished Visiting Scientist Adrian Hooke, Scott Burleigh, Leigh Torgerson Bob Durst, Keith Scott Industry: – – • Adrian Hooke MITRE: – • Vint Cerf JPL: – • Keith Scott Eric Travis, Global Science and Technology Howard Weiss, Sparta Advisors: – Bob Braden (USC); Len Kleinrock (UCLA); Dave Mills (UDEL); Deborah Estrin (UCLA); Joe Touch (USC); John Wroclawski (MIT); Jon Crowcroft (UCL); John Klensin (ATT); and others Leigh Torgerson

Beginnings: The Interplanetary Internet 1998 1999 2000 2001 2003 2002 2004 2005 RFC-5050 BUNDLE PROTOCOL Title Author(s) Filename Pages Date Interplanetary Internet (IPN) Architectural Definition V. Cerf et al. draft-irtf-ipnrg-arch-00. txt 58 18 -May-01 This document describes the Interplanetary Internet - a communication system to provide Internet-like services across interplanetary distances in support of deep space exploration. Our approach, which we refer to as bundling, builds a storeand-forward overlay network above the transport layers of underlying networks. Bundling uses many of the techniques of electronic mail, but is directed toward interprocess communication, and is designed to operate in environments that have very long speed-of-light delays. A URL for this Internet-Draft is http//www. ietf. org/internet-drafts/draft-irtf-ipnrg-arch 00. txt 2006 2007 2008

Delay/Disruption-Tolerant Networking 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 JAXA DRTS 2019 ISS Missions ECOSTRESS CAL + ~38 others LADEE/LLCD ISS – SCa. N TESTBED DTN on Lunar Gateway

DTN Design Elements • Don’t replace terrestrial networking or legacy comm link technology • OVERLAY NETWORK! • Don’t reinvent reliable link technology • TCP/IP on land, Prox-1 for orbiter-to-surface • Deep Space Links needed a reliable link – so Licklider Transmission Protocol (LTP) was developed • Deal with loss and delay since contiguous end-to-end paths may be rare • Provide a store-and-forward mechanism at each node in the network • Fix what the IP design missed 40+ years ago • Build in security and integrity • Provide for Quality of Service • Deal with different routing needs of underlying networks • Pre-planned contact plans for space networks, opportunistic routing for ad-hoc situations, IP routing on the ground. • Design in provisions for network management, security key management, reliable multicast, projected data transfer types, etc. • Asynchronous Management Protocol (DTN-AMP), Delay-Tolerant Key Administration (DTKA), reliable multicast, special protocols for streaming video and applications that need in-order delivery

DTN Stack Overview

DTN for Human Space Flight - i. PAS DTN 2019 • Using Integrated Power, Avionics and Software (i. PAS) distributed testbed between JPL and JSC. • Please see You. Tube video at https: //youtu. be/c. TZQJX 5 C 4 Ws

Benefits of DTN • Improved Operations: • Store-and-forward mechanism • Automatic retransmission • Contact-based routing • Interoperability and Reuse: • CCSDS-standardized DTN protocol International interoperability / reuse • Space Link Efficiency and Robustness: • Reliable links and automatic retransmissions link efficiency • Error-corrected data throughput more usable bandwidth • DTN Contact Graph Routing multiple network paths and automation of routing of data. • Security: • Bundle Security Protocol (BSP) end-to-end encryption and integrity checks. • Quality of Service: • 256 priority levels which can be set for each individual data item • Allows sharing of links with a minimum of mission control management.

Loss Recovery Loops -- Legacy vs DTN

What DTN Software is Available? • Many public implementations available – DTN 2 for university research and terrestrial uses; DTN also available in Java, C, Python – even for Android. • For space use, ION is the NASA standard • Interplanetary Overlay Network • Available on Source. Forge https: //sourceforge. net/projects/ion-dtn/ Contents: • BP • LTP • Various convergence layers for LTP, TCP/IP, UDP/IP • Applications • AMS, BSSP, CFDP, DTPC • Performance & Network Monitoring • DTN-AMP • NASA provides encryption modules, convergence layers for TM/TC/AOS

Current Programs Using DTN 2019+ • ISS • Ops side (email / files) • Payload ops – either direct or using ISS DTN Gateway • (ECOSTRESS, CAL, and about 38 other experiment packages) • • GSFC PACE mission (FPGA, high-speed downlink implementation) Cube. Sats (implementing DTN in the IRIS radio) – Lunar Ice. Cube and others KARI lunar program HEOMD baseline for Lunar Gateway; commencing testing this year

AES Project DTN Deployment Plan FY 18 – Operational Usage FY 19 – Increasing Capabilities ION 3. 6. 2 ION 3. 6. 1 ISS DTN GW H/W Upgrade, ION 3. 6. 1 TRe. K Demo, HRF, ECOSTRESS SCa. N NASA Infusion IPV 6 port “Sticky” Routing OCGR Contact History Exch Scalability Node Auto-config Arcturus Future Architecture Studies Advocacy KARI Commercial Infusion OGA Missions Node Auto-configuration Congestion Forecasting High-Rate Support Information Centric Networking Gateway Next. STEP Habitat Mission & Infrastructure Infusion Incorporate DTN into Ground and Flight Segments (RF and Optical) Ground Testing, Consulting, Payload Planning Industry Engagement, SBIR Opportunity Identification Architecture Consultation LTP Simplifications Contact plan maturity Bundle deliv times EM-1 Cubesats High-Rate DTN Development HEO/SMD Study NASA ION COMPLETE ENCODE Avionics & SW Integration including CFS Gateway Partners AES ION 3. 6. 4 ION 3. 6. 3 AMP Implementation Security Policy update Bug fixes Android port Windows installer SBSP update Features added to RTEMS port CGR SABR update FY 20+ – Widespread Usage Significant Operational Use KPLO Support Establish Pilots R&D/Proof of Concept IETF Standards Architecture Inclusion Commercial Products Widespread Use of DTN 18

Infusion Support to Space Missions Core DTN Development Team at JPL can provide resources for: • System Engineering - Rapid prototyping of multiple node (spacecraft or ground) scenarios with docker containers with actual DTN software • ION incorporation in flight software and radios, • End-to-end communications and data system analysis, modeling, simulation and prototyping • Testing of implementations from Mission Ops to Spacecraft with AMMOS and DSN included • Future RF-in-the-loop testing with DTF-21

PTL EEIS Gold Standard Testbed

For More Information Associated with the Internet Society: http: //ipnsig. org NASA DTN Site https: //www. nasa. gov/content/dtn

Thank you for attending! Questions?

• BACKUP SLIDES

The DTN “Bundle” e 2 e Applications (e. g. , CFDP, CCSDS Packet, VOIP, Video) Bundle API Bundle Fragmentation & Reassembly Bundle Agent Management Services Bundle Expiration Security Key Management Bundle Encryption Bundle end-end Integrity Bundle Custody Transfer DTN Bundle and Bundle Agent Functions Bundle Routing Convergence Layer (specific adapters that map Bundles to underlying transmission services) LTP CCSDS- Space Packet or Encap Packet CCSDS TM/TC/AOS CCSDS Proximity Link UDP/IP TCP/IP SONET Ethernet

Legacy Comm Protocols versus DTN is an IMPROVEMENT to current methods, not a replacement 1. 2. 3. 4. DTN BP and LTP improve CFDP routing and reliability, automating timer settings DTN/LTP automates multiplexing and prioritization of file and stream data LTP provides for optional reliable stream data, with or without DTN bundle protocol Same use of CFDP means DTN is transparent to end user or FSW file creation ops L. Torgerson – 8/24/11

System Engineering Realities Spending money in Phase C/D to save money/improve Mission Ops in Phase E is difficult because of the fact that Mission Ops isn’t usually funded until after launch, so no early investment by Mission Ops managers is possible. DTN should be specified and planned for in Phases A & B! Engage Mission Ops and Science Teams as early as possible.