Delay-Tolerant Payload Conditioning (DTPC) Protocol Specification

The Bundle Protocol version 7 handles the hop-by-hop transmission of data units (bundles) across Delay and Disruption Tolerant Networks (DTNs). While BPv7 guarantees store-and-forward bundle carriage, it deliberately omits strict end-to-end transport-layer controls like packet sequencing, redundancy elimination, and targeted retransmissions. Consequently, these responsibilities are often forced directly onto individual applications. The Delay-Tolerant Payload Conditioning (DTPC) protocol provides an application-independent service layer sitting immediately above BPv7 and below application clients . DTPC executes strictly at the endpoints of the communication path, optimizing data conditioning and link utilization without demanding modification from intermediate routers .

DTPC encompasses the following distinct application support facilities:

In-Order Delivery Support: Delivers application items to the destination client in transmission order, safeguarding application logic against variable network path delays.
Controlled Aggregation: Bundles multiple small Application Data Units (ADUs) sharing an identical destination and profile into a single compressed bundle payload to mitigate BP header overhead.
Application-Controlled Elision: Removes redundant or outdated data items from an outbound aggregation queue based on an application-defined profile.
End-to-End Reliability: Implements end-to-end positive (ACK) and negative (NAK) signaling paired with reactive timers to manage data loss.
Duplicate Suppression: Captures and drops redundant application data items arriving via multiple network segments.

DTPC operates as a thin management layer positioned between the application and the Bundle Protocol Agent (BPA). It tracks communication paths by matching discrete "Topic IDs". +-----------------------------------------+ | Application Client | +-----------------------------------------+ | (Topic Registration) v +-----------------------------------------+ | Delay-Tolerant Payload Conditioning | | (DTPC) | +-----------------------------------------+ | (Aggregated Payloads) v +-----------------------------------------+ | Bundle Protocol Agent (BPA) | +-----------------------------------------+

An application interacts with a local DTPC entity by binding to a specific unsigned integer Topic ID. The API surface incorporates three primary service primitives modeled on the ION reference implementation :

dtpc_open(topicID, elisionFn): Registers the client as the definitive handler for a given topic and assigns an application-specific elision callback hook.
dtpc_send(destinationEID, profile, aduLength, aduBuffer): Submits an individual ADU to the outbound staging system.
dtpc_receive(sap, aduBuffer, bytesReceived): Delivers verified, sequenced ADUs directly to the target application thread.

DTPC exchanges structural operational units wrapped as standard Bundle Protocol payload blocks. The primary formats include the Data PDU and the Ack PDU.

Data PDUs transport aggregated or standalone application payloads. Fields are encoded sequentially:

PDU Type (4 bits): Set to 0x01 for Data PDU.
Flags (4 bits): Reserved for framing and extension signaling.
Topic ID (Variable Length CBOR): Identifies the target application service framework.
Profile ID (Variable Length CBOR): Dictates aggregation limits and reliability requirements (e.g., ACK required, NAK required).
Sequence Number (Variable Length CBOR): A monotonically increasing counter unique to the Sender-Recipient-Topic triplet.
Payload Length (Variable Length CBOR): Length of the trailing aggregated application data block.
Payload: The raw concatenated Application Data Units.

Ack PDUs convey end-to-end receipt metrics back to the original source.

PDU Type (4 bits): Set to 0x02 for Ack PDU.
Flags (4 bits): Reserved.
Topic ID (Variable Length CBOR): Matches the target sequence domain.
Ack Count (Variable Length CBOR): Number of sequence ranges reported in this frame.
Sequence Ranges (Array of CBOR pairs): Pairs of sequence bounds [Start, End] indicating successfully delivered or missing payloads.

To protect constrained space links from protocol bloat, dtpc_send places incoming ADUs into an outbound topic buffer queue.

Length Constraints: Transmission is immediately triggered if adding the next ADU causes the aggregated buffer to exceed a maximum size parameter.
Time Constraints: A configurable countdown timer runs when items inhabit the buffer. If the timer hits zero before the length threshold is reached, the buffer is packaged for delivery, sent as a bundle payload, and cleared of content.
Elision Processing: Upon receipt of application data and resultant insertion into the queue as a PDU, the protocol passes the PDU to the application's registered elisionFn. This allows the application to replace outdated or superseded PDUs to be flushed from the queue and replaced with fresh entries, conserving network bandwidth.

When the Profile ID requests acknowledgment:

Transmission Logging: The DTPC source maintains a copy of the outgoing Data PDU in a local retransmission database and initializes an estimated Retransmission Timeout (RTO) timer.
ACK/NAK Processing: Upon receiving an Ack PDU, the source cleans acknowledged entries from its log. If an explicit sequence gap is identified via negative indicators, or if an RTO timer expires, the affected segments are systematically placed on the queue again for retransmission.

Well-Known Service Registration This document requests IANA to register the following entry in the "'ipn' Scheme URI Well-Known Service Numbers for BPv7" registry established by : +=======+==============+=================+ | Value | Description | Reference | +=======+==============+=================+ | 129 | DTPC Service | (this document) | +-------+--------------+-----------------+ For the IPN scheme, the service number is appended to the node number; for example, ipn:2.2.129 is the DTPC service on Allocator ID 2, node number 2. Note: Existing implementations use service number 129 for bundle reception, and 128 for sending. As sending need not be bound to a Well-Known service number, it is suggested that implementations send via a service number Reserved for Private Use per RFC9758.

Security Considerations DTPC relies fundamentally on the Bundle Protocol Security framework (BPSec) to enforce transport authorization, payload integrity, and confidentiality. Applications requiring end-to-end verification must coordinate cryptographic keys prior to establishing a DTPC session.