How does delay-tolerant networking (DTN) work?

Internet protocols were designed around a set of assumptions that RFC 4838 spells out: that an end-to-end path exists between source and destination for the whole session, that retransmissions based on timely feedback from the receiver can repair errors, and that end-to-end loss is relatively small. A spacecraft behind a planet, a sensor visited by a passing vehicle, or a phone that only meets other phones now and then breaks all three.

Delay-tolerant networking (DTN) relaxes those assumptions. Its design principles in RFC 4838 include using variable-length messages rather than streams, using storage inside the network to support store-and-forward operation over long timescales, not requiring end-to-end reliability, and letting applications say how long their data stays useful. It works as an overlay: a bundle layer that sits above the transport layers of the networks it connects.

An application hands the bundle layer a complete message. The bundle layer turns it into one or more bundles, each a sequence of blocks: one primary block first, carrying addressing and timing, then any extension blocks, then exactly one payload block. Sources and destinations are named by endpoint identifiers (EIDs), which can refer to a single node or to a group of nodes.

Every bundle carries a creation time and a lifetime. In Bundle Protocol version 7 (RFC 9171) the lifetime is the number of milliseconds after creation at which the payload stops being useful. Once a bundle’s age passes its lifetime, nodes need no longer keep or forward it, and it should be deleted. For nodes without accurate clocks, RFC 9171 defines a Bundle Age block that records how much time has passed since the bundle was created, and it lets a node impose a shorter local lifetime on a bundle that would otherwise overload it. This is the DTN version of a message TTL.

Bundles can also be split into fragments when a link can only carry part of one, and the fragments can be reassembled anywhere in the network.

A node with a bundle to send waits for a contact, which RFC 4838 defines as a period during which a link to another node has capacity. It names several kinds:

• Persistent contacts are always available, like an always-on internet connection.
• On-demand contacts need an action to start, like a dial-up link, then behave like persistent ones.
• Scheduled contacts happen at known times, like a pass of a low-earth-orbit satellite.
• Opportunistic contacts appear unexpectedly, like a Bluetooth link to a kiosk as someone walks past it.
• Predicted contacts are guessed from the history of earlier contacts.

When contacts are known in advance, a node can plan which bundles to send in each one. When they are not, routing becomes much harder, and RFC 4838 describes it as an open research area. The opportunistic networking approach handles the unpredictable case by passing data to whichever devices happen to meet.

DTN nodes connect through very different links, so the bundle layer does not talk to them directly. A convergence-layer adapter (CLA) sends and receives bundles over one kind of underlying network and gives the bundle layer a consistent interface. RFC 4838 notes that a convergence layer over TCP might only need to add message boundaries, while one over a network without reliable transport might have to provide reliability, fragmentation and flow control itself. RFC 9171 requires a TCP convergence layer to be implemented when bundles need to be forwarded over the Internet.

Inside a node, RFC 9171 tracks each bundle’s retention constraints. A new bundle starts as “Dispatch pending”, becomes “Forward pending” while the node tries to send it on, and cannot be discarded while any constraint remains. If a send attempt fails, the node may try again. If no next hop or convergence layer can be found, forwarding is “contraindicated”: the node either declares forwarding failed or keeps the bundle and resumes forwarding once the obstacle clears, which is the store-and-forward step written into the protocol.

For reliability beyond a single link, the original architecture defines custody transfer. A node that accepts custody of a bundle becomes its custodian, takes over responsibility for retransmitting it, and signals acceptance to the previous custodian, which can then free its resources. RFC 4838 compares this to a database commit. RFC 9171 moved custody transfer out of the core protocol into the separate bundle-in-bundle encapsulation specification.

Nodes can also send bundle status reports when they receive, forward, deliver or delete a bundle, so that a sender can learn how far its data got. Each report is itself a bundle, and RFC 9171 warns that requesting reports for large numbers of bundles could cause an unacceptable increase in traffic. Generating them must be disabled by default, and even when enabled each node decides whether to send one. These reports, and acknowledgments in general, are how a sender learns what happened without a live connection.

RFC 5050 published the experimental Bundle Protocol in 2007. RFC 9171 standardised version 7 with lessons from implementation and deployment, and its implementations are not interoperable with RFC 5050 ones. NASA describes DTN as a store-and-forward approach for space communications. It reports that its PACE mission began using DTN operationally for housekeeping telemetry in 2024, and that since its DTN Project finished in January 2026, DTN has been an operational service in both its Near Space Network and Deep Space Network.