| Internet-Draft | DTPC Protocol | September 2026 |
| Johnson | Expires 31 March 2027 | [Page] |
This document specifies the Delay-Tolerant Payload Conditioning (DTPC) protocol. DTPC is an end-to-end, connectionless, expandable application service protocol designed to operate directly above the Bundle Protocol (BPv7). It provides transparent application data conditioning services across challenged networks, including controlled aggregation of Application Data Units (ADUs), application-specific elision, transmission-order tracking, end-to-end positive/negative acknowledgments, and duplicate suppression. DTPC preserves the end-to-end principle across delay-tolerant networks where intermediate nodes execute store-and-forward operations.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 31 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Bundle Protocol version 7 [RFC9171] 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 [ION-DTPC]. DTPC executes strictly at the endpoints of the communication path, optimizing data conditioning and link utilization without demanding modification from intermediate routers [DTPC-Paper].¶
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 [ION-DTPC]:¶
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 [RFC9758]:¶
+=======+==============+=================+ | Value | Description | Reference | +=======+==============+=================+ | 129 | DTPC Service | (this document) | +-------+--------------+-----------------+¶
Table 1: DTPC Service Registration¶
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.¶
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.¶