1 in-space cross support using delay / disruption tolerant networking keith scott 15 october, 2008...
TRANSCRIPT
1
In-Space Cross Support UsingDelay / Disruption Tolerant Networking
Keith Scott
15 October, 2008Berlin, Germany
October 15, 2008
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
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
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
Relevant Properties of DTN for Cross-Support in Space
“UDP-Like” messaging paradigmusing application-layer PDUscalled ‘bundles’• Unicast / multicast• DTN handles getting the bundles to
the 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
source
destination
disrupted areas
Time t
Time t+n
October 15, 2008
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
Persistent StorageCT Custody Transfer Capability
Bundle PathCustody 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
GroundStation
Deep Space
DTN (Potential delay)
LTP
Encap
AOS Prox-1
Mars RelaySatellite
IP Router
ATM
DS-1
CT CT CT CT
MissionControl
MarsRover
LTP
Encap
LTP
Encap
October 15, 2008
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
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
Multi-Agency Cross-Support
Control Center
Control Center
Control Center
Elements:AgenciesRoversSurface relaysOrbital relays
GEO / Direct Comm Mission
LEO/MEOEarth OrbitInter-Network
Mars Orbit And SurfaceInter-Network
Lunar OrbitAnd SurfaceInter-Network
October 15, 2008
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
Backup
October 15, 2008
13
IP Packet Format
Version HeaderLength Total length
Identification
TTL Protocol Header Checksum
Source IP Address
Destination IP Address
Flags Fragment offset
DSCPECN
DATA
October 15, 2008
14
CCSDS Space Packets
PacketVersionNumber
PacketIdentification
Packet Sequence Control
PacketData
LengthPkt
TypeSec.HdrFlag
Application Process Identifier
Sequence Flags
Packet Sequence Count or Packet
Name
3 bits 1 bit 1 bit 11 bits 2 bits 14 bits 16 bits
2 octets 2 octets 2 octets
Packet Primary Header
October 15, 2008
15
Creation Stamp1
Version Flags
Blocklength
DestinationScheme
DestinationSSP
SourceScheme
SourceSSP
Report-toScheme
Report-toSSP
Custodianscheme
CustodianSSP
CreationStamp2 Lifetime
DictionaryLength
Dictionary
FragmentOffset
TotalADU length
BlockType
Primary BundleBlock
ControlFlags
Block Length
Payload
Bundle PayloadBlock
32 bits
October 15, 2008
16
source
destination
disrupted areas
Time t
Time t+n
October 15, 2008
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
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
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