Blog 011

DTN Interoperability between ION and µD3TN Bundle Protocol implementations

By Alberto Montilla Ochoa • June 2022

Testing DTN interoperability at the application level.

Over the last month, Spatiam Corporation collaborated with D3TN GmbH ( and the Interplanetary Networking Special Interest Group (IPNSIG, to carry out connectivity tests between two bundle protocol version 7 (BPv7) implementations: ION (Interplanetary Overlay Network) from NASA/JPL (, and µD3TN, by D3TN ( On their latest versions, both ION (version 4.1.1) and µD3TN (version 0.11.0) support BP version 7, the latest definition for the bundle protocol (IETF RFC 9171).

The IPNSIG's Pilot Projects Working Group (PWG) initiated an ongoing project to connect its members and form a DTN Network. Spatiam Corporation and D3TN, together with other organizations and individual members, are part of the PWG DTN Network, which currently has over 20 nodes connected. Connectivity opportunities in the network vary between nodes, some nodes are continuously connected to the network, while others are occasionally switched on. Network participants run DTN applications to test connectivity between nodes; for example ION's 'bpecho' and 'bping' allow for nodes to ping each other, and 'bpsink' and 'bpsource' provide simple messaging between nodes. Most of the network is made up of DTN nodes implementing ION, and a goal of the PWG's initiative is to support a variety of DTN implementations, requiring application interoperability between them, meaning that both configuration and implementation efforts are necessary.

Spatiam Corporation previously partnered with D3TN in a series of tests that involved sending bundles through the European Space Agency (ESA) OPS-SAT CubeSat. You can find our report on these experiments here: In these experiments an ION node managed by Spatiam Corporation was placed in between two µD3TN nodes, acting as a network relay. While ION was involved in the network (BP) and transport (TCP) layers, it had no awareness of the application that was running end to end (from µD3TN to µD3TN nodes). Hence, application interoperability between ION and µD3TN was not tested.

Spatiam Corporation's DTN Manager (, has worked as one of the platforms that support the IPNSIG network, acting as a node database and a tool to automate the generation of network configuration parameters.

Therefore the experiments that were carried out had the following objective:

  • Determine configuration parameters to connect ION and µD3TN nodes (extending the findings of the OPS-SAT experiments since µD3TN now supports both DTN and IPN naming schemes).
  • Update the generation of network parameters to support µD3TN nodes in Spatiam's DTN Network Manager.
  • Test interoperability between ION and µD3TN applications.

ION and µD3TN Configuration

Note: From this point on, this guide will assume that both ION and µD3TN have been compiled successfully, and that your network permissions allow for both implementations to communicate with each other. For compilation guides please refer to ION's latest release here: ( and µD3TN's latest release here: ( (note that µD3TN Python utils will also need to be installed).

ION supports a variety of convergence layers including (LTP, TCP, and UDP), and µD3TN currently supports TCP, therefore ION needs to be configured to communicate with µD3TN nodes via TCP.

Both implementations now support the IPN scheme, and this guide will utilize it as the de facto scheme for space. Note that the DTN scheme is also supported in both ION and µD3TN and can be used alternatively (this was the case in the OPS-SAT Experiment).

This experiment had the following setup:

ION Configuration

ION node 100 (IPN scheme) had the following configuration file, note the comments explaining key lines:

## begin ionadmin
1 100 ''

m horizon +0

# Series of 1-hour contacts
a contact +0 +3600 100 100 10000000 1
a contact +0 +3600 200 100 10000000 1
a contact +0 +3600 100 200 10000000 1
a contact +0 +3600 200 200 10000000 1

# Series of 1-hour ranges
a range +0 +3600 100 100 1
a range +0 +3600 200 100 1
a range +0 +3600 100 200 1
a range +0 +3600 200 200 1

m production 10000000
m consumption 10000000
## end ionadmin

## begin ionsecadmin
## end ionsecadmin

## begin ltpadmin
1 32

# LTP span for loopback connection
a span 100 32 32 1400 10000 1 'udplso <Node_100_External_IP>:1113' 300

s 'udplsi'
## end ltpadmin

## begin bpadmin
a scheme ipn 'ipnfw' 'ipnadminep'
a endpoint ipn:100.0 q
a endpoint ipn:100.1 q
a endpoint ipn:100.2 q

a protocol ltp 1400 100

# TCP protocol declaration
a protocol tcp 1400 100

# LTP and TCP inducts
a induct ltp 100 ltpcli
a induct tcp <Node_100_Internal_IP>:4556 tcpcli

a outduct ltp 100 ltpclo

# TCP outduct to node 200
a outduct tcp <Node_200_External_IP>:4556 ''

## end bpadmin
## begin ipnadmin
a plan 100 ltp/100

# IPN plan of node 200
a plan 200 tcp/<Node_200_External_IP>:4556

## end ipnadmin

With this configuration, ION will start and perform a TCP handshake with node 200.

µD3TN Configuration

µD3TN node 200 was started with the following command:

./build/posix/ud3tn -e "ipn:200.0" -c "tcpclv3:<Node_200_Internal_IP>,4556" -s tmp/ud3tn200.socket

And the contact to node 100 was added with the following command:

python tools/aap/ --socket tmp/ud3tn200.socket --schedule 1 3600 10000 --reaches "ipn:100" ipn:100.0 tcpclv3:<Node_100_External_IP>:1113

Spatiam's DTN Network Manager

You can now add µD3TN nodes in your DTN network overlays with the DTN Manager.

DTN Manager - Add Node screen.

When a new node is added, two new parameters are expected: Convergence layer (TCP or LTP), and DTN Implementation (ION or µD3TN). The first parameter, convergence layer, will determine how the node configuration is generated for network nodes. Currently we support configuration generation for ION nodes (planning to support µD3TN configuration generation in a future release). The second parameter, DTN implementation, defines the implementation configuration details.

Users can now create interoperable overlay networks and download configuration (with contact plans) accordingly.

DTN Manager - Test network used for the experiment.

Interoperable Applications

ION comes with a variety of applications to transfer simple messages, files, test connectivity, and monitor traffic. µD3TN uses the Application Agent Protocol (AAP) to support the creation of applications through a simple socket-based interface. Included with the software are a series of AAP applications to transfer messages and test connectivity.

The table below summarizes the applications that were tested in this experiment:

Application Description
bpsink (ION) Simple console-like application for receiving bundles and printing their contents.
bptrace (ION) Sends a bundle through the network to enable a forwarding trace based on bundle status reports.
bpsource (ION) Simple console-like application for interactively sending text strings in bundles to a specified DTN endpoint.
bping (ION) Send and receive Bundle Protocol echo bundles.
bpecho (ION) Bundle receiver that sends an “echo” acknowledgment bundle back upon reception of each bundle.
aap_receive (µD3TN) Register an agent with uD3TN and wait for bundles.
aap_send (µD3TN) Send a bundle via uD3TN's AAP interface.
aap_ping (µD3TN) Send bundles to a given EID, wait for responses, and print them.
aap_ech (µD3TN) Sends received bundles back to the sender.

Bptrace and aap_send forward string messages to be received by bpsink and aap_receive. These applications are interoperable, so bptrace can forward messages to aap_receive, and aap_send can communicate to bpsink. Note that bpsource is also interoperable, it can send messages to bpsink and to aap_receive, however bpsource forwards 'anonymous bundles' (no bundle origin is set) so aap_receive will log received bundles from 'dtn:none'.

Similarly, bping and aap_ping send a series of pings that will be replied to by bpecho and aap_echo. This set of applications are interoperable as well.

The following commands were used call the above applications between ION node 100 and µD3TN node 200.


bptrace own_endpoint_ID destination_endpoint_ID report-to_endpoint_ID TTL class_of_service "trace_text" [status_report_flags]
bptrace ipn:100.1 ipn:200.1 ipn:100.1 300 0.2.254 "bptrace_msg" rcv,ct,fwd,dlv,del

AAP_SEND [-h] [--socket PATH | --tcp IP PORT] [-a AGENTID] [-v] [--bibe] dest_eid [payload]
python tools/aap/ --socket tmp/ud3tn200.socket --agentid 1 "ipn:100.1" "Message Payload"


bpsource destination_endpoint_ID
bpsource ipn:200.1


bpsink ownEndpointId
bpsink ipn:100.1

AAP_RECEIVE [-h] [--socket PATH | --tcp IP PORT] [-a AGENTID] [-v] [-c COUNT] verify-pl VERIFY_PL]
python tools/aap/ --socket tmp/ud3tn200.socket --agentid 1


bping [-c count] [-i interval] [-p priority] [-q wait] [-r flags] [-t ttl] srcEID destEID [reporttoEID]
bping ipn:100.1 ipn:200.1

AAP_PING [-h] [--socket PATH | --tcp IP PORT] [-a AGENTID] [-v] [-i INTERVAL] [-c COUNT] destination
python tools/aap/ --socket tmp/ud3tn200.socket --agentid 1 "ipn:100.1"


bpecho ownEndpointId
bpecho ipn:100.1

AAP_ECHO [-h] [--socket PATH | --tcp IP PORT] [-a AGENTID] [-v]
python tools/aap/ --socket tmp/ud3tn200.socket --agentid 1

On light: µD3TN CLI On Dark: ION CLI.

In the first test series, the above commands were run by Spatiam Corporation using an internal network with the setup explained above, achieving success in transferring bundles between the two implementations.

Then, same tests were run in cooperation with D3TN GmbH, who hosted a µD3TN node which we were able to ping successfully after setting up our network configuration via Spatiam’s DTN Manager. Note that µD3TN contacts to our node were added manually by D3TN GmbH.

We would like to thank the D3TN team and Oscar Garcia from IPNSIG PWG for their support in running these tests.

We hope the guidelines provided in this document facilitate further testing between ION and µD3TN as well as other implementations.

contact us

follow us

Spatiam Corporation Logo

Spatiam Corporation ©