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 environmentsCCSDS Space Packets

• Pros: Mature protocol for space communications• Cons: Lacks some features like source and destination

addresses in packetsDelay / 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 fashionFor 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

DSCP ECN

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 FlagsBlocklength

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-connectedThe 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