New DTN Capabilities

Scott Burleigh, JPL2 November 2011

2

Overview

• Collaboration between JPL and DUTH• Delay-Tolerant Payload Conditioning (DTPC)• Bundle Streaming Service (BSS)• Bundle Delivery Time Estimation (BDTE)

11/2/2011

3

JPL/DUTH Collaboration

• Space Internetworking Center (SPICE) established at Democritus University of Thrace in Xanthi, Greece, 1 September 2010.– Staff includes several grad students, postdocs and programmers.– Center is funded for exchange study projects.

• DUTH/SPICE Staff collaborated with JPL:– Giorgos Papastergiou (DTPC)– Sotirios-Angelos Lenas (BSS)– Nikolaos Bezirgiannidis (BDTE)

11/2/2011

4

DELAY-TOLERANTPAYLOAD CONDITIONING

11/2/2011

5

Motivation

• DTN Green Book requirements– In-order delivery (4.2.2.3.6)– Suppression of duplicate data (E.4.4.1)

• MCTSSA study wish list– Situational awareness system: large volume of small data items,

isochronous transmission, so heavy overhead and degraded link utilization.

– Needed data item aggregation into larger bundles.– Needed data item elision – removal of obsolete or redundant data

items from aggregated bundles.

• Standardize support for BP end-to-end acknowledgment flag.

11/2/2011

6

Design

• What all these requirements have in common is that they need operate only at the endpoints, not within the network; they don’t need to be built into BP.– Functionally, a transport-layer protocol above BP – the DTN analog to

TCP, except that it must not be the primary reliability mechanism.– Note: could also do UDP-like end-to-end integrity checksum here (as is

done in CFDP and AMS at the same layer).

11/2/2011

7

Stack

11/2/2011

application

IP

TCPCL

BP

DTPC

application

TCP

EthernetEthernet

IP

TCPCL

BP

DTPC

TCPLTP

encap

AOS

BP

LTPCL

LTP

encap

AOS

LTPCL

8

Transmission Profile

• Profile ID number• Characteristics common to aggregated application data items.

– Custody control flag– Lifetime– Report-to EID– Class of service– Extended class of service– Status reports requested– Maximum number of retransmissions– Aggregation size limit– Aggregation time limit

11/2/2011

9

Other Terms

• Topic– Functionally, an application identifier; serves as mux/demux token

within aggregated application data unit.– Topic ID number.

• Aggregator– Site for aggregation of data items (on any number of topics) sharing

the same profile and destination EID– Sequence counter

• Collector– Site for delivery of data items (on any number of topics) sharing the

same profile and source EID– Handles DTPC ADUs in sequence number order, suppressing duplicates

11/2/2011

10

Protocol Data Units

11/2/2011

contentlength Payload record (PR)

PR counttopic ID Topic block (TB)PR PR PR. . .

sequence nbrprofile ID DTPC application data unitTB TB TB. . .type flag

Record length, topic ID, PR count, profile ID, and sequence number are all SDNVs.

Type flag is 0 for data, 1 for acknowledgment only (no topic blocks).

Status

• Version 1.0 was delivered 24 August 2011.• Not yet integrated into ION.• Started an Internet Draft for this protocol, but

nothing ready to post yet.– Should be a CCSDS Blue Book instead?

12

BUNDLE STREAMING SERVICE

11/2/2011

13

Motivation

• MSFC requirements for streaming video over a delay-tolerant network– Data must never be presented out-of-order.– Streaming display must never be delayed while waiting for lost data to

be retransmitted.– But all data must be transmitted reliably for non-real-time review of

the complete data stream.

11/2/2011

14

Design

• Use two convergence-layer ducts for each pair of neighbors on the end-to-end path for the streaming data.– One duct uses a best-efforts (unreliable) CL protocol such as UDP or

“green” LTP. Bundles of streaming data that are in ascending bundle creation time are sent over this duct in the order in which they arrive.

– The other duct uses a reliable CL protocol such as TCP or “red” LTP. Each bundle whose creation time isn’t greater than that of the newest bundle (in the same stream) forwarded from this node is sent over this duct to ensure eventual arrival.

• Forwarder daemon (router) is modified to track bundle order.• Receiving application uses a library that supports both real-

time display and playback.• Sending application need not do anything special for BSS.11/2/2011

P/B view

Operation

11/2/2011 15

i

obssfw

e o

Source App

i

obssfw

oi

i

i e

o

Dest App

Recv thread

R/T fn

Main thread

lib bssbss

db

R/T view

Status

• Version 0.4 was delivered 10 October 2011.• Integrated into ION, not yet posted to open source.• Conference paper planned but not written yet.

17

BUNDLE DELIVERY TIME ESTIMATION TOOL

11/2/2011

18

Motivation

• Required by SISG in SSI Operations Concept Section 3.2 Planning Principles:– PL-4: “Users will need to know the predicted epoch by which a given

forward product will reach the destination node.”– PL-5 “It shall be possible to identify all provider components’ latency

and the resulting earliest/latest physical delivery times under normal conditions of SSI network operation.”

11/2/2011

19

Design

• Collect processing statistics on all nodes of network, using Network Management functions; store the statistics in a database.

• Given a bundle’s source endpoint, creation time, size, lifetime, and destination endpoint:– Use the CGR algorithm to predict the route from the source to the

destination.– Use contact plan information on node ranges to compute earliest

possible arrival time via this route.– Use processing statistics to predict the probability of data loss and

retransmission (increasing latency) on each leg of the route.– Plot the net probability of each plausible combination of successful

and unsuccessful transmissions, to determine plausible latest arrival.

11/2/2011

20

Status

• Initial prototype demonstrated on 7 October 2011.• Development continuing.

11/2/2011