1 / 19

In-Space Cross Support Using Delay / Disruption Tolerant Networking

In-Space Cross Support Using Delay / Disruption Tolerant Networking. Keith Scott 15 October, 2008 Berlin, Germany. [My Notion of] Context. CCSDS has defined, implemented, and is deploying cross-support on the ground

ehren
Download Presentation

In-Space Cross Support Using Delay / Disruption Tolerant Networking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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

  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

  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…)

  5. Relevant Properties of DTN for Cross-Support in Space Time t Time t+n • “UDP-Like” messaging paradigmusing application-layer PDUscalled ‘bundles’ • Unicast / multicast • DTN handles getting the bundles tothe destinations, regardless oflocation • 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

  6. Capabilities vs. Policy Actual Relay Opportunities Mission Operations Geometry • Policy • Science Constraints • Contingency Operations • Other • 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

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

  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

  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

  10. Multi-Agency Cross-Support

  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

  12. Backup

  13. IP Packet Format

  14. CCSDS Space Packets Packet Primary Header

  15. Time t Time t+n

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

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

  18. Stuff To Do Moving the bits • Packet formats • Protocol definition • [Easy] • 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 • 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]

More Related