New DTN capabilities

Download Report

Transcript New DTN capabilities

New DTN Capabilities

Scott Burleigh, JPL 2 November 2011

Overview

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

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 3

11/2/2011

DELAY-TOLERANT PAYLOAD CONDITIONING

4

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 5

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 6

11/2/2011 application DTPC BP LTPCL LTP encap AOS

Stack

LTPCL LTP encap AOS BP TCPCL TCP IP Ethernet application DTPC BP TCPCL TCP IP Ethernet 7

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 8

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 9

11/2/2011

Protocol Data Units

length content Payload record (PR) topic ID PR count PR PR . . .

PR Topic block (TB) profile ID sequence nbr type flag TB TB . . .

TB DTPC application data unit 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).

10

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?

11/2/2011

BUNDLE STREAMING SERVICE

12

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 13

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 14

Operation

Source App e bssfw o o i bssfw o o bss db lib bss Main thread Dest App Recv thread R/T fn i e o P/B view R/T view 11/2/2011 i i i 15

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.

11/2/2011

BUNDLE DELIVERY TIME ESTIMATION TOOL

17

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 18

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 19

Status

• • Initial prototype demonstrated on 7 October 2011.

Development continuing.

11/2/2011 20