1. 1 In-Space Cross Support Using Delay / Disruption Tolerant Networking Keith Scott 15 October, 2008 Berlin, Germany October 15, 2008

2. 2 [My Notion of] Context  CCSDS has defined, implemented, and is deploying cross-support on the ground Cross-support between one agency’s control center and another agency’s ground station SLE / CSTS  No current standards for space-to-space cross support above the data link layer October 15, 2008

3. 3 Space-to-Space Cross Support  Mars Exploration Rovers / Mars Odyssey approach was expedient, but inefficient  Packet-based service, as opposed to a bitstream service, desirable  Current Prox-1 implementations at Mars would make CFDP difficult to cross-support, but in principle CFDP should be a cross-supported file transfer protocol in space and on the ground  CFDP primarily implements file transfer together with metadata  AMS defines a messaging protocol for connected, low-latency environments; Remote AMS can connect AMS continua  Routed service would support lander-orbiter-lander comms as well as lander-orbiter-Earth comms  Given current CCSDS protocol suite, an internetworking layer (in the OSI sense) is needed Internetworking spans multiple data links, such as Proximity-1 and TC/TM October 15, 2008

4. 4 Internetworking Layer Options  Internet Protocol (IP) Pros: Very mature protocol suite Cons: Implementations not well-suited for long-delay and/or intermittently-connected environments  CCSDS Space Packets Pros: Mature protocol for space communications Cons: Lacks some features like source and destination addresses in packets  Delay / Disruption Tolerant Networking (DTN) Pros: Designed to handle intermittency and space environment Cons: Immature for space (but working on it…) October 15, 2008

5. 5 Relevant Properties of DTN for Cross- Support in Space  “UDP-Like” messaging paradigm using application-layer PDUs called ‘bundles’ Unicast / multicast DTN handles getting the bundles to the destinations, regardless of location - DTN layer implements routing Optional (set by application) reliability 3-level priority No guarantees of in-order delivery, duplicate suppression  CCSDS Space Packet can be used as an application-layer protocol Data identification, application sequencing, …  Other protocols like CFDP / AMS can sit directly on top of DTN Time t Time t+n October 15, 2008

6. 6 Capabilities vs. Policy  We need to specify the capabilities we want to provide now because: It’s difficult to add new capabilities later It’s even more difficult to retrofit new capabilities into existing systems later Drive out advanced ops concepts now  We do not have to invoke all of those capabilities from the beginning May use dynamic routing, can use static routing May provide cross-support to other agencies, may not (special case of next) Definitely policy, science constraints, contingency operations, … will all affect what cross-support can be provided by a particular asset  Cross-support agreements between agencies (policy, not technical) need NOT be ‘hard’ commitments Geometry Mission Operations Policy Science Constraints Contingency Operations Other Actual Relay Opportunities October 15, 2008

7. 7 Persistent Storage CTCustody Transfer Capability Bundle Path Custody Acknowledgements DTN for Multi-Hop Space Communications Application DTN TCP IPv6 Ethernet UTP DTN (potential delay) TCP IPv6 ATM DS-1 IPv6 Ethernet UTP Orbit-to-SurfaceTerrestrial Network LTP Encap AOS Application DTN Prox-1 Ground Station Deep Space DTN (Potential delay) LTP Encap AOSProx-1 Mars Relay Satellite IP Router ATM DS-1 CT Mission Control Mars Rover LTP Encap LTP Encap October 15, 2008

8. 8 Operations Concept  Users / applications emit data when it suits them, without regard to end-to-end connectivity Applications don’t have to worry about the destination of the location or whether there’s a network path or not When the source and destination are connected, bundles flow in “real-time” When source and destination are not connected, bundles move in store-and-forward fashion  For commands, applications may want to use time- triggered command sequences Send command sequence ahead of time, allowing for store-and-forward delivery Sequence is invoked at a particular time carried as part of the command October 15, 2008

9. 9 Applications  CCSDS Space Packet can be used as an application-layer protocol  CFDP can be re-factored to use DTN Solves advanced CFDP scenarios October 15, 2008

10. 10 Multi-Agency Cross-Support October 15, 2008

11. 11 Status of DTN  Internet Research Task Force Working Group Stable protocol specification Active and ongoing research work for terrestrial applications  CCSDS DTN WG Draft Green Book out – criteria for evaluating candidate protocols Target is to adopt / adapt Internet RFC5050  NASA Constellation Carrying DTN as a requirement in the C3I Interoperability Specification  NASA DTN-for-2010 project Advance DTN to TRL-8 by 2010 DINET (Scott)  IOAG’s Space Internetworking Strategy Group (SISG) Report / presentation to IOAG in September Draft report / presentation to IOP in November Conclusions: The agencies need to move towards a network-centric model of communications using some combination of IP, Space Packets, and DTN October 15, 2008

12. 12 Backup October 15, 2008

13. 13 IP Packet Format October 15, 2008

14. 14 CCSDS Space Packets Packet Version Number Packet Identification Packet Sequence Control Packet Data Length Pkt Type Sec. Hdr Flag Application Process Identifier Sequence Flags Packet Sequence Count or Packet Name 3 bits1 bit 11 bits2 bits14 bits16 bits 2 octets Packet Primary Header October 15, 2008

15. 15 October 15, 2008

16. 16 Time t Time t+n October 15, 2008

17. 17 Required Services (from the standpoint of Applications)  Applications need: To send/receive delimited application-layer PDUs To send those PDUs end-to-end through a possibly multi-hop infrastructure To be able to communicate when the infrastructure is only intermittently-connected  The infrastructure needs to support: Multiple applications at each end node Multiple end nodes multiplexed onto the infrastructure October 15, 2008

18. 18 What We Have Now  Space Packets Addressing requires elements from the frame (spacecraft ID) 11-bit APID is available and could be re-purposed (but 11 bits isn’t a lot to identify end systems, intermediate systems, and applications)  CFDP (as a network layer) October 15, 2008

19. 19 Stuff To Do October 15, 2008 Moving the bits Packet formats Protocol definition [Easy] Exposing ‘resources’ to other projects / agencies SM&C [Hard, independent of internetwork protocol] Registering information End system IDs [Easy] Service Level Agreements What does AgencyA commit to providing [Hard, independent of internetwork protocol] Possible Mission Planning Models: It’s a giant network free-for-all [no] I plan my mission to use my agency’s resources only, and throw any spare resources into the ‘common’ pot And I sometimes take from the ‘common’ pot