Conference PaperPDF Available

Interplanetary Overlay Network: An Implementation of the DTN Bundle Protocol

Authors:
Scott Burleigh at California Institute of Technology
Scott Burleigh
Download full-text PDF
Read full-text
Download citation

Abstract

First Page of the Article
Content uploaded by Scott Burleigh
Author content
All content in this area was uploaded by Scott Burleigh on Aug 10, 2015
Content may be subject to copyright.
Interplanetary Overlay Network
An Implementation of the DTN Bundle Protocol
Scott Burleigh
Jet Pro
p
ulsion Laborator
y
py
California Institute of Technology
Pasadena, California
Scott.Burleigh@jpl.nasa.gov
12 January 2006
1
Back
g
round
g
• Reference implementation for the DTN Bundle
Pt l(BP)iDTN2 iti dtUCBkl
P
ro
t
oco
l (BP) i
s
DTN2
, ma
i
n
t
a
i
ne
d
a
tUCB
er
k
e
l
ey.
– Designed as a research vehicle.
Widely used well supported
–
Widely used
,
well supported
.
• Most DTN researchers are investigating terrestrial
applications for which DTN2 works very well
applications
,
for which DTN2 works very well
.
• Space flight applications impose different constraints,
motivatin
g
develo
p
ment of an alternative BP
gp
implementation for use in space flight missions.
• Interplanetary Overlay Network (ION) is a space flight
implementation of BP, developed at NASA’s Jet
Propulsion Laboratory.
12 January 2006
2
Constraints on a Fli
g
ht Im
p
lementation
gp
• Link constraints
All i ti i l ll l t i
–
All
commun
i
ca
ti
ons are w
i
re
l
ess, genera
ll
y s
l
ow, asymme
t
r
i
c.
• From spacecraft to ground: 256 Kbps to 6 Mbps.
• From ground to spacecraft: 1 to 2 Kbps.
– Links are very expensive, virtually always oversubscribed.
– Fine-grained transmission, small bundle payloads.
•
.
• Processor constraints
– Flight processors typically run real-time operating systems
(V W k ® RTEMS™) l ki t t d d l
(V
x
W
or
k
s
®
,
RTEMS™) l
ac
ki
ng pro
t
ec
t
e
d
memory mo
d
e
l
s.
– Robustness is paramount. No malloc and free or standard
new and delete; must not crash other flight software.
– Processing efficiency is important:
• Slow (radiation-hardened) processors.
•
Relatively slow non
-
volatile storage: flash memory.
12 January 2006
3
Relatively slow non
volatile storage: flash memory.
ION’s Diver
g
ence From DTN2
g
Design Element DTN2 ION Rationale
L
C
C
Piffii
L
anguage
C
++
C
P
rocess
i
ng e
ffi
c
i
ency, memory
management visibility.
Memory management new,delete PSM No dynamic system memory
management permitted
management permitted
.
Non-volatile storage
management Berkeley DB,
RDBMS (MySQL) SDR persistent
objects Processing efficiency, footprint.
Locus of processing dtnd daemon
process, separate
routing engine
highly distributed:
forwarders, ducts,
applications, and
admin tools
Robustness (module simplicity,
incremental upgrade; prevent
head-of-line blocking); simplify
flow control.
admin tools
flow control.
Locus of node state (e.g.,
queues) private memory
of dtnd daemon shared memory Support distributed functionality,
limit impact of demand spikes.
Application Programming
remote procedure
shared library
Support real
time operations:
Application Programming
Interface
remote procedure
calls to dtnd
shared library
functions act on
shared memory
Support real
-
time operations:
prevent blocking, support
deterministic execution.
Endpoint IDs in bundle’s only ASCII URIs supports CBHE Bandwidth efficiency.
12 January 2006
4
primary block in dictionary
Implementation Layers
ION
SLit
SDR
ZCO
Operating System
PSM
S
m
Li
s
t
SDR
Platform
Operating System
ION Interplanetar
y
Overla
y
Network libraries and daemons
yy
ZCO zero-copy objects capability: minimize data copying up and down the stack
SDR Spacecraft Data Recorder: persistent object database in shared
memory, using PSM and SMList
SmList linked lists in shared memory using PSM
PSM Personal Space Management: memory management within a
pre-allocated memory partition
Platform common access to O.S.: shared memory, system time, IPC mechanisms
Operating System POSIX thread spawn/destroy, file system, time
12 January 2006
5
Com
p
ressed Bundle Header Encodin
g
pg
• For a CBHE-conformant scheme, every endpoint ID is
scheme name
:
element nbr
service nbr
scheme
_
name
:
element
_
nbr
.
service
_
nbr
– 65,535 schemes supported. Up to 16,777,215 elements (i.e.,
nodes) per scheme. Up to 65,535 services per scheme.
–
Service
~= “
demux token
”
or IP protocol number All administrative
Service demux token or IP protocol number
.
All administrative
bundles are service number zero.
• CBHE limits primary bundle header length to 34 bytes.
–
Dictionary not needed so it
’
s omitted
–
Dictionary not needed
,
so it s omitted
.
Destination offsets Source offsets Report-to offsets Custodian offsets
N
CBHE
Scheme SSP Scheme SSP Scheme SSP Scheme SSP
N
on-
CBHE
Common
Scheme
number
Destination
Element number Source
Element number Report-to
Element number Custodian
Element number
Service
Number
for source &
destination
CBHE
12 January 2006
6
ION Database Structure
inbound
bundles application process
endpoints schemes bundles to
forward
incomplete
(inbound)
bundles
ION database
timeline
inducts
all bundles (waiting
for TTL expiration)
timeline
convergence
layer input
forwarder
CL
protocols
outducts
outbound
bdl
DTN clock
forwarder
outducts
b
un
dl
es
convergence
ltt
12 January 2006
7
l
ayer ou
t
pu
t
Processin
g
Flow
Application
g
send receive
delivery
queue
forwarding
forwarding
queue
Forwarder
transmission
queue
ION database
CLO
local protocol
CLI
local protocol dispatch
12 January 2006
8
Performance
DTN Bandwidth Tests
800
900
600
700
800
b
its/second)
2 nodes DTN2 RAM
3 nodes DTN2 RAM
5120
10240
15360
20480 51200 102400204800
25600
300
400
500
g
e Data Rate (M
b
2 nodes DTN2 disk
3 nodes DTN2 disk
2 nodes ION RAM
3 nodes ION RAM
110 100
500750
1024
0
100
200
Avera
g
1.00E+00 1.00E+01 1.00E+02 1.00E+03 1.00E+04 1.00E+05 1.00E+06
Data Size (Kilobytes)
IONfliht ft f t it b t708kilbt i ldi SDRdtb t t
12 January 2006
9
ION fli
g
ht
so
ft
ware
f
oo
t
pr
i
n
t
: a
b
ou
t 708 kil
o
b
y
t
es
i
nc
l
u
di
ng
SDR d
a
t
a
b
ase managemen
t
sys
t
em.
Evaluation Co
p
ies Distributed To Date
p
• NASA
Goddard Space Flight Center
–
Goddard Space Flight Center
– Marshall Space Flight Center
– Ames Research Center
Gl R h C t
–
Gl
enn
R
esearc
hC
en
t
e
r
– Johnson Space Center
– Constellation project
• Other US
– Johns Hopkins University Applied Physics Laboratory
– Cal Poly San Luis Obispo
– Ohio University
– MITRE Corporation
–
In
te
rf
ace & Co
n
t
r
o
l
Syste
m
s
te ace & Co t o Syste s
• ESA (European Space Agency)
• CNES (French national space agency)
12 January 2006
10
Status of ION
• Conforms to version 4 of the BP specification (August
2006) U d t i 5 (D b 2006) i i
2006)
.
U
pgra
d
e
t
o vers
i
on
5(D
ecem
b
er
2006) i
s
i
n
progress.
Implements c stod transfer stat s reports deli er
•
Implements c
u
stod
y
transfer
,
stat
u
s reports
,
deli
v
er
y
options, priority, reassembly from fragments, flow
control congestion control
control
,
congestion control
.
• Tested in Red Hat Linux 8+, Fedora Core 3+, on 32-
bit and 64-bit
p
rocessors. Also in VxWorks 5.4 on
p
PowerPC 750.
• Interoperability with DTN2 (and other Bundle Protocol
implementations: C# .Net, Symbian) demonstrated at
IETF in San Diego, November 2006.
12 January 2006
11
Summar
y
y
• ION is an implementation of the Delay-Tolerant
Nt ki B dl P t lthti d i df
N
e
t
wor
ki
ng
B
un
dl
e
P
ro
t
oco
lth
a
ti
s
d
es
i
gne
df
or use
in spacecraft flight software.
Testing to date s ggests that it ill be s itable for this
•
Testing to date s
u
ggests that it
w
ill be s
u
itable for this
purpose.
•
Development and evaluation are continuing
•
Development and evaluation are continuing
.
12 January 2006
12
End
of
File
... While substantial efforts have been invested in developing and assessing DTN and deep-space-related protocol stacks [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], there is a pressing requirement for a tool that generates and visualizes authentic, extensive network topologies and sheds light on the dynamics of IPN topologies. Addressing the interdisciplinary gap, this tool must bridge the divide between the intricate celestial mechanics familiar to astronomers and the network design principles customary to software engineers, harmonizing both domains' expertise in advancing interplanetary communication. ...
... Usage guidelines, example files, and the Unity project, including the website code, are available in [19]. 2 V's compute module include landers and orbiters as nodes based on Keplerian models implemented to mimic actual space dynamics. The compute module allows the export of realistic contact plans, following standards such as NASA's ION [6] and HDTN [9] formats. ...
... Delay Tolerant Networking [3] based on Bundle Protocol [4] rendered several notable implementations arguing in favor of the interest in IPN. Interplanetary Overlay Network (ION) [5], [6], developed by NASA's JPL, is a comprehensive stack. IONE [7] mirrors ION but introduces experimental features. ...
IPN-V: The Interplanetary Network Visualizer
Preprint
Full-text available
  • Sep 2024
The Interplanetary Network (IPN) emerges as the backbone for communication between various spacecraft and satellites orbiting distant celestial bodies. This paper introduces the Interplanetary Network Visualizer (IPN-V), a software platform that integrates interplanetary communications planning support, education, and outreach. IPN-V bridges the gap between the complexities of astrodynamics and network engineering by enabling the generation and assessment of dynamic, realistic network topologies that encapsulate the inherent challenges of space communication, such as time-evolving latencies and planetary occlusions. Leveraging the power of Unity 3D and C#, IPN-V provides a user-friendly 3D interface for the interactive visualization of interplanetary networks, incorporating contact tracing models to represent line-of-sight communication constraints accurately. IPN-V supports importing and exporting contact plans compatible with established space communication standards, including NASA's ION and HDTN formats. This paper delineates the conception, architecture, and operational framework of IPN-V while evaluating its performance metrics.
View
... In particular, interplanetary data transfer (IP-DT) faces unique challenges in dynamic and unstable topologies caused by the movement and obstruction of network nodes and limited bandwidth and extremely long delays due to vast distances in DS communications. These challenges can be partially overcome by delay tolerant networking (DTN) [15,16], which improves the reliability and efficiency of IP-DT over unreliable and ultra-long-latency links using store-carry-forward (SCF). ...
On the Scaling of Reliable Interplanetary Networks with Deep Reinforcement Learning
Conference Paper
Full-text available
  • Mar 2025
The rapid development of deep space exploration missions has led to the continuous expansion of interplanetary networks (IPNs) for enhanced data transfer capacities and reliability. In this paper, we propose a novel deep reinforcement learning (DRL) framework for optimizing the scaling of IPN topologies (i.e., the placement of relay satellites), such that the routing and data scheduling of interplanetary data transfer (IP-DT) in the scaled IPN achieves maximized performance gain. Our proposal leverages graph neural networks (GNNs) to extract topological correlations within an IPN and hereby learns progressive local rewriting policies for approaching the optimal solution. Extensive simulations verify the effectiveness and robustness of our proposal, showing that the learned relay satellite placements facilitate higher reliability (in terms of data delivery ratios) and lower end-to-end latency for different IPN scenarios, when compared with the existing benchmarks.
View
... Therefore, it is pertinent to investigate routing and data scheduling of IP-DTs specifically, which has spurred recent studies on the topic [35][36][37][38][39]. In addition to theoretical approaches, the Jet Propulsion Laboratory (JPL) has developed and opensourced the interplanetary overlay network (ION) project [44,45], providing a software platform for simulating and validating bundle-based protocols and algorithms for IPN. ...
On the Rate Control and Information Exchange for Optimizing Data Transfers in IPNs
Article
Full-text available
  • Nov 2024
Recently, the growing of deep space explorations has attracted notable interests on interplanetary network (IPN), which is the key infrastructure for communications across vast distances in the solar system. However, the unique characteristics of IPN pose numerous unexplored challenges for interplanetary data transfers (IP-DTs), i.e., the challenges that existing schemes developed for Earth-based networks are ill-equipped to handle. To address these challenges, we first propose a novel distributed algorithm that leverages the Lyapunov optimization to jointly optimize the routing, scheduling and rate control of IP-DTs at each node. Specifically, our proposal adaptively optimizes the data-rate and bundle scheduling at each output port of a node, significantly improving the end-to-end (E2E) latency and delivery ratio of IP-DTs under a long-term energy constraint. Then, we further explore the heterogeneity of IPN to introduce limited state information exchange among nodes, and devise mechanisms for generating and disseminating state messages to facilitate timely adjustments of routing and scheduling schemes in response to unexpected link disruptions and traffic surges. Simulations verify the advantages of our proposal over the state-of-the-arts.
View
... An alternative algorithmic implementation would be to use Interplanetary Overlay Network (ION) [23] [24]. However, we have not chosen it because our main focus is on CGR. ...
Improved Contact Graph Routing in Delay Tolerant Networks with Capacity and Buffer Constraints
Preprint
Full-text available
  • Oct 2024
Satellite communications present challenging characteristics. Continuous end-to-end connectivity may not be available due to the large distances between satellites. Moreover, resources such as link capacity and buffer memory may be limited. Routing in satellite networks is therefore both complex and crucial to avoid packet losses and long delays. The Delay Tolerant Network (DTN) paradigm has emerged as an efficient solution for managing these challenging networks. Contact Graph Routing (CGR), a deterministic routing algorithm, is one of the most popular DTN algorithms. CGR is compatible with the ``store, carry, and forward" principle, whereby a node receives a message and stores it in its buffer until a transmission opportunity becomes available. However, CGR relies on simplified models to incorporate potential constraints in the route search. For instance, the linear volume assumption is often used to consider capacity constraints. Moreover, capacity management and buffer management are mostly performed during the forwarding phase, once an issue has occurred. In this paper, we propose to take measures before or during the route search in order to find routes that respect both contact-capacity limits and node-buffer limits. We introduce the contact splitting and edge pruning operations to effectively account for the routing constraints. This ensures that CGR outputs the optimal solution among the subset of valid solutions. The proposed approach can also be used to book resources to be used in case of issues during the forwarding step.
View
View
View
View
View
Comparing Statistical, Analytical, and Learning-Based Routing Approaches for Delay-Tolerant Networks
Article
  • May 2024
In delay-tolerant networks (DTNs) with uncertain contact plans, the communication episodes and their reliabilities are known a priori. To maximise the end-to-end delivery probability, a bounded network-wide number of message copies are allowed. The resulting multi-copy routing optimization problem is naturally modelled as a Markov decision process with distributed information. In this paper, we provide an in-depth comparison of three solution approaches: statistical model checking with scheduler sampling, the analytical RUCoP algorithm based on probabilistic model checking, and an implementation of concurrent Q-learning. We use an extensive benchmark set comprising random networks, scalable binomial topologies, and realistic ring-road low Earth orbit satellite networks. We evaluate the obtained message delivery probabilities as well as the computational effort. Our results show that all three approaches are suitable tools for obtaining reliable routes in DTN, and expose a trade-off between scalability and solution quality.
View
View
Autonomous Congestion Control in Delay-Tolerant Networks
Article
Full-text available
  • Jul 2008
Congestion control is an important feature that directly affects network performance. Network congestion may cause loss of data or long delays. Although this problem has been studied extensively in the Internet, the solutions for Internet congestion control do not apply readily to challenged network environments such as Delay Tolerant Networks (DTN) where end-to-end connectivity may not exist continuously and latency can be high. In DTN, end-toend rate control is not feasible. This calls for congestion control mechanisms where the decisions can be made autonomously with local information only. We use an economic pricing model and propose a rule-based congestion control mechanism where each router can autonomously decide on whether to accept a bundle (data) based on local information such as available storage and the value and risk of accepting the bundle (derived from historical statistics). Preliminary experimental results show that this congestion control mechanism can protect routers from resource depletion without loss of data. Nomenclature ACK = acknowledgement CT-ACK = custody-transfer acknowledgement DTN = Delay-Tolerant Network
View
View
View
International collaboration makes a deep impact in space
  • Nov 2005
  • J Kelley
J. Kelley, " International collaboration makes a deep impact in space ", ISO Focus, October 2005.
Delay Tolerant Network Architecture
  • V Cerf