Delay/Disruption Tolerant Networking S. Johnson Internet-Draft Spacely Packets, LLC Intended status: Standards Track 27 September 2026 Expires: 31 March 2027 Delay-Tolerant Payload Conditioning (DTPC) Protocol Specification draft-johnson-dtn-dtpc-00 Abstract 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. Status of This Memo 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 Notice 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 Johnson Expires 31 March 2027 [Page 1] Internet-Draft DTPC Protocol September 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Functional Capabilities . . . . . . . . . . . . . . . . . . . 2 3. Architecture and Service Primitives . . . . . . . . . . . . . 3 3.1. Architectural Figure . . . . . . . . . . . . . . . . . . 3 4. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 4 4.1. Data PDU Format . . . . . . . . . . . . . . . . . . . . . 4 4.2. Ack PDU Format . . . . . . . . . . . . . . . . . . . . . 4 5. Operational Procedures . . . . . . . . . . . . . . . . . . . 5 5.1. Aggregation and Elision . . . . . . . . . . . . . . . . . 5 5.2. Reliability Engine . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction 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]. 2. Functional Capabilities DTPC encompasses the following distinct application support facilities: Johnson Expires 31 March 2027 [Page 2] Internet-Draft DTPC Protocol September 2026 * *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. 3. Architecture and Service Primitives 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) | +-----------------------------------------+ 3.1. Architectural Figure 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]: 1. dtpc_open(topicID, elisionFn): Registers the client as the definitive handler for a given topic and assigns an application- specific elision callback hook. 2. dtpc_send(destinationEID, profile, aduLength, aduBuffer): Submits an individual ADU to the outbound staging system. Johnson Expires 31 March 2027 [Page 3] Internet-Draft DTPC Protocol September 2026 3. dtpc_receive(sap, aduBuffer, bytesReceived): Delivers verified, sequenced ADUs directly to the target application thread. 4. Protocol Data Units (PDUs) DTPC exchanges structural operational units wrapped as standard Bundle Protocol payload blocks. The primary formats include the *Data PDU* and the *Ack PDU*. 4.1. Data PDU Format 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. 4.2. Ack PDU Format 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. Johnson Expires 31 March 2027 [Page 4] Internet-Draft DTPC Protocol September 2026 * *Sequence Ranges (Array of CBOR pairs):* Pairs of sequence bounds [Start, End] indicating successfully delivered or missing payloads. 5. Operational Procedures 5.1. Aggregation and Elision 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. 5.2. Reliability Engine When the Profile ID requests acknowledgment: 1. *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. 2. *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. 6. IANA Considerations 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]: Johnson Expires 31 March 2027 [Page 5] Internet-Draft DTPC Protocol September 2026 +=======+==============+=================+ | 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. 7. 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. 8. References 8.1. Normative References [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9758] Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025, . 8.2. Informative References [ION-DTPC] California Institute of Technology / Jet Propulsion Laboratory, "Interplanetary Overlay Network (ION) Open Source Software", n.d., . [DTPC-Paper] "Delay Tolerant Payload Conditioning protocol", ScienceDirect Elsevier Computer Networks, Vol 57, 2014. Author's Address Johnson Expires 31 March 2027 [Page 6] Internet-Draft DTPC Protocol September 2026 Scott Johnson Spacely Packets, LLC 46 High Ridge Rd Holly Hill, FL 32117 United States of America Email: scott@spacelypackets.com Johnson Expires 31 March 2027 [Page 7]