Delay/Disruption Tolerant Networking F. Flentge Internet-Draft European Space Agency Intended status: Standards Track 26 October 2026 Expires: 29 April 2027 Compressed Bundle Status Reporting for Bundle Protocol Version 7 draft-flentge-dtn-compressed-status-reporting-00 Abstract This document defines compact, aggregated status reporting for Bundle Protocol Version 7. A Compressed Reporting Extension Block assigns sequence information and optionally requests reports, while a Compressed Reporting Signal reports events for multiple bundles. 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 29 April 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 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. Flentge Expires 29 April 2027 [Page 1] Internet-Draft Compressed Bundle Status Reporting October 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Compressed Reporting Extension Block . . . . . . . . . . . . 3 4.1. 1-Element Form: Sequence Number Only . . . . . . . . . . 3 4.2. 2-Element Form: Sequence Number and Identification . . . 4 4.3. 3-Element Form: Reporting-Request with implicit source . 4 4.4. 4-Element Form: Reporting-Request with explicit block source . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.5. 5-Element Form: Reporting-Request with explicit report-to EID . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.6. Malformed CREBs . . . . . . . . . . . . . . . . . . . . . 5 5. Compressed Reporting Signal . . . . . . . . . . . . . . . . . 6 6. Reporting Procedures . . . . . . . . . . . . . . . . . . . . 6 7. End-to-End Use . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. In-Sequence Delivery . . . . . . . . . . . . . . . . . . 7 7.2. Duplicate Suppression . . . . . . . . . . . . . . . . . . 7 7.3. Gap Detection . . . . . . . . . . . . . . . . . . . . . . 8 7.4. Bundle Accounting . . . . . . . . . . . . . . . . . . . . 8 7.5. Reliability . . . . . . . . . . . . . . . . . . . . . . . 8 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 8 9. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 12. Operational and Manageability Considerations . . . . . . . . 10 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 14.1. Normative References . . . . . . . . . . . . . . . . . . 10 14.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Standard BPv7 status reporting, as defined in [RFC9171], generates one report bundle for each reportable event such as reception, forwarding, delivery or deletion of a bundle. As this can create excessive network traffic, bundle status reports must be disabled by default. Building on the corresponding CCSDS experimental specification [CCSDS-734.6-O-1], this document defines compact reporting in which a Compressed Reporting Extension Block (CREB) supplies sequence information and optionally requests reports, and a Compressed Reporting Signal (CRS) aggregates events for multiple bundles. Flentge Expires 29 April 2027 [Page 2] Internet-Draft Compressed Bundle Status Reporting October 2026 This document depends on the sequence-identification framework in [I-D.flentge-dtn-bundle-sequence-identification]. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Block Source Administrative Endpoint ID (AEID): An endpoint ID of the administrative element of the BP agent that assigns a Bundle Sequence Number and inserts the corresponding Compressed Reporting Extension Block. Compressed Reporting Signal (CRS): An administrative record sent to a report-to endpoint to provide bundle status information on a set of bundles. Compressed Reporting Extension Block (CREB): A BPv7 extension block which requests compressed reporting of bundle status. 3. Applicability The mechanism is intended for DTNs where aggregating reports materially reduces signaling overhead. CREBs can be forwarded by nodes that do not implement this specification, but reports are generated only by supporting nodes. Deployment policy must account for incomplete support and possible loss or delay of reporting signals. 4. Compressed Reporting Extension Block Compressed Reporting is requested by adding a Compressed Reporting Extension Block (CREB). The CREB MUST use the BPv7 canonical block format according to [RFC9171]. Block Type 14 as assigned by IANA for CREB MUST be used. A bundle MAY contain multiple CREBs inserted by the same or different nodes. Using CBOR as defined by [RFC8949], the block-type-specific data MUST be a definite-length CBOR byte string containing a definite-length array of one to five elements as defined below. 4.1. 1-Element Form: Sequence Number Only For an array-length of 1, the array SHALL contain: Flentge Expires 29 April 2027 [Page 3] Internet-Draft Compressed Bundle Status Reporting October 2026 * Item 1 SHALL be a Bundle Sequence Number (BSN), a CBOR unsigned integer, as specified in [I-D.flentge-dtn-bundle-sequence-identification]. The block source AEID SHALL be implicitly given by the source node EID in the primary block of the bundle. Only the source node MAY use the 1-Element Form. This form does not request creation of aggregate reports but can, for example, be used by a receiving node to detect gaps in bundle sequences or restore the order of bundles. 4.2. 2-Element Form: Sequence Number and Identification For an array-length of 2, the array SHALL contain: * Item 1 SHALL be as defined in Section 4.1 * Item 2 SHALL be a Bundle Sequence ID (BSID), a CBOR unsigned integer, as specified in [I-D.flentge-dtn-bundle-sequence-identification]. The block source AEID SHALL be implicitly given by the source node EID in the primary block of the bundle. Only the source node MAY use the 2-Element Form. This form does not request creation of aggregate reports but can, for example, be used by a receiving node to detect gaps in bundle sequences or restore the order of bundles. 4.3. 3-Element Form: Reporting-Request with implicit source For an array-length of 3, the array SHALL contain: * Item 1 and Item 2 SHALL be as defined in Section 4.2 * Item 3 SHALL contain the Status Report Request flags which SHALL be processed as a bit field indicating the flag values for the following reporting requests: - Bit 0 - reception; - Bit 1 - forwarding; - Bit 2 - delivery; - Bit 3 - deletion; - Bit 4 - custody acceptance; - Bit 5 - custody rejection; Flentge Expires 29 April 2027 [Page 4] Internet-Draft Compressed Bundle Status Reporting October 2026 - Bit 6 and higher - reserved for future use. Custody-related reporting is for informational purposes only and should not be confused with custody signals that trigger the behavior defined in Custody Procedures [I-D.flentge-dtn-bpv7-custody-transfer]. The intention is to enable the reporting of custody-related behavior to a report-to node that is different from the current custodian, which is the receiver of all custody signals. Only the bundle source MAY use the 3-Element Form. The block source AEID and report destination SHALL be implicitly given by the source node EID in the primary block of the bundle and MUST identify an administrative endpoint capable of receiving the CRS. 4.4. 4-Element Form: Reporting-Request with explicit block source For an array-length of 4, the array SHALL contain: * Item 1 to Item 3 SHALL be as defined in Section 4.3 * Item 4 SHALL be the block source AEID of the node which inserted the CREB, a CBOR encoded endpoint ID as specified in [I-D.flentge-dtn-bundle-sequence-identification]. CRSs are sent to this AEID (see Section 6). 4.5. 5-Element Form: Reporting-Request with explicit report-to EID For an array-length of 5, the array SHALL contain: * Item 1 to Item 4 SHALL be as defined in Section 4.4 * Item 5 SHALL be a report-to EID, a CBOR encoded endpoint ID as specified in [I-D.flentge-dtn-bundle-sequence-identification]. CRSs are sent to this report-to EID (see Section 6). 4.6. Malformed CREBs A node MUST treat a CREB as malformed if its array length is outside one through five, field types are invalid, reserved flag bits are set contrary to this specification, or the array form violates the source or EID constraints. It MUST apply the block processing control flags according to BPv7 and MUST NOT generate reports from malformed request data. Flentge Expires 29 April 2027 [Page 5] Internet-Draft Compressed Bundle Status Reporting October 2026 5. Compressed Reporting Signal The Compressed Reporting Signal (CRS) is used to transmit aggregated status reports. A CRS MUST be a BPv7 administrative record. Administrative Record Type 14 as assigned by IANA for the CRS MUST be used. The content of the CRS administrative record MUST be a CBOR map with the following key/value pairs: * CRS Event Codes as keys; an unsigned CBOR integer - 0 - reception; - 1 - forwarding; - 2 - delivery; - 3 - deletion; - 4 - custody acceptance; - 5 - custody rejection; - Values above 5 - reserved for future use; A receiver MUST ignore an unrecognized event code while processing recognized entries in the same map. CRS event codes are specific to this specification and are distinct from the Bundle Status Report Reason Codes registered for BPv7 status reports. * Bundle Sequence Collections as specified in [I-D.flentge-dtn-bundle-sequence-identification] as values. A sequence in a CRS MUST include its block source AEID only when the report-to EID differs from the administrative endpoint of the node that inserted the CREB, namely the 5-Element Form. For the 3- and 4-Element Forms, the CRS receiver is the block source and that AEID is implicit. 6. Reporting Procedures Reception of a valid 3-, 4-, or 5-Element CREB MUST cause a supporting node to retain the information needed to report each requested event that occurs. The retained information includes CRS event code, BSN, BSID, source Node ID, destination EID, Block Source EID and report-to EID as available and required. Flentge Expires 29 April 2027 [Page 6] Internet-Draft Compressed Bundle Status Reporting October 2026 The CRS destination MUST be the bundle's source node ID for a 3-Element CREB, the block source AEID for a 4-Element CREB, and the report-to EID for a 5-Element CREB. A node SHALL generate and transmit CRSs from stored disposition information to the CRS destination according to configuration or external events. CRS generation and transmission MAY be based on: * periodic timers, * size constraints for the CRS (bundle size or number of reported bundles), supplemented by a timer to prevent indefinite delays when the size limit is not reached but there are no additional bundles to report, * external events such as link establishment or explicit commands to send CRS. Once a CRS for a specific bundle has been transmitted, no other reporting signal for this bundle SHOULD be generated with the same event code. 7. End-to-End Use Compressed Reporting can be used to realize various End-to-End Services. Sequence-only CREBs (1- and 2-Element Form) can support in-sequence delivery, duplicate suppression, and gap detection without CRS generation. Delivery and deletion CRSs can provide end- to-end accounting and can be used to trigger retransmission of bundles from the source to enable reliable bundle delivery. The services described in the following sections are not mutually exclusive, so they can be combined without the need for additional extension blocks. 7.1. In-Sequence Delivery CREB sequence numbers based on separate counters per destination EID (BSID '0') enable bundle re-ordering at destination. Lost or delayed bundles can be handled using timeouts. 7.2. Duplicate Suppression Duplicate suppression works similarly to the in-sequence delivery. When CREB sequence numbers use separate counters per destination EID (BSID '0'), duplicated bundles can be detected by the same sequence number and suppressed. This is more efficient than using time stamps as it allows more compact storage of information about received bundles. Flentge Expires 29 April 2027 [Page 7] Internet-Draft Compressed Bundle Status Reporting October 2026 7.3. Gap Detection End-to-end gap detection can also be based on BSNs using separate counters per destination EID (BSID '0'). Out-of-order bundle arrivals can be addressed by implementing a time window before reporting a gap, to wait for late arrivals with lower sequence numbers than the current maximum. 7.4. Bundle Accounting The use of CRSs for delivery or deletion of bundles allows for end- to-end accounting of bundles towards the bundle source node (using Section 4.3), the block source AEID (using Section 4.4), or a different report-to EID (using Section 4.5). For delivery reporting, only the destination node must support CRS. For deletion accounting, both the destination and deleting nodes must support CRS. If the deleting node does not support CRS, failed delivery can still be inferred from a missing delivery report. However, cases where the reporting signal is lost may result in wrongly assumed delivery failure. 7.5. Reliability Using the end-to-end accounting mechanism described above, end-to-end reliability can be provided by re-forwarding a bundle when an expected delivery report has not been received or the bundle has been reported as deleted. Re-forwarding a bundle again over the full end- to-end path is usually inefficient, so this mechanism may be combined with Custody Transfer as specified in [I-D.flentge-dtn-bpv7-custody-transfer]. In this way, re-forwarding will typically happen between custodians with re-forwarding from the source required only if Custody Transfer fails. 8. Fragmentation A bundle containing a CREB MUST NOT be fragmented. A CREB MUST NOT be added to or processed in a fragment. Sources SHOULD set the Bundle Must Not be Fragmented flag. 9. CDDL The following CDDL uses the CDDL notation of [RFC8610] and the rules defined by [RFC9171]. Flentge Expires 29 April 2027 [Page 8] Internet-Draft Compressed Bundle Status Reporting October 2026 ;CREB $extension-block /= extension-block-use<14, embedded-cbor> creb-data = [ seq-num: uint, ? seq-id: uint, ? status-request-flags: uint, ? blk-source: eid, ? report-to-eid: eid ] ;CRS $admin-record /= [14, reporting-signal-content] reporting-signal-content = { 0 => seq-collection, 1 => seq-collection, 2 => seq-collection, 3 => seq-collection, 4 => seq-collection, 5 => seq-collection, * uint => seq-collection } 10. IANA Considerations IANA has assigned Bundle Block Type 14 to the Compressed Status Reporting Extension Block and Bundle Administrative Record Type 14 to the Compressed Reporting Signal, with CCSDS 734.6-O-1 as the current reference. IANA is requested to add this document as a reference for both registrations upon publication as an RFC. 11. Security Considerations Reports can reveal traffic patterns and delivery state. Forged requests can amplify traffic toward a victim report-to EID, while forged signals can corrupt accounting or trigger unnecessary retransmission. Nodes MUST authorize report requests and destinations and MUST bound stored report state and transmission rate. Deployments SHOULD use BPSec [RFC9172] integrity protection for CREBs and CRS administrative records where authentication and integrity are required, and confidentiality protection where reporting data is sensitive. Flentge Expires 29 April 2027 [Page 9] Internet-Draft Compressed Bundle Status Reporting October 2026 12. Operational and Manageability Considerations Implementations should expose report aggregation timers and thresholds, pending report state by destination and event, generated and received CRS counts, duplicate reports, malformed CREBs and CRSs, authorization failures, discarded requests, and resource-limit events. 13. Implementation Status This section records implementation experience in accordance with [RFC7942] and is intended to be removed before publication as an RFC. The European Space Agency Bundle Protocol implementation supports CREB and CRS encoding and processing, sequence-only and reporting- request forms, event collection, timer- and size-triggered aggregation, and compressed signal transmission. The mechanisms have been validated with unit tests, simulations, and a simulated lunar communication scenario involving a relay orbiter, rover, ground station, and control centers. The implementation information reflects the status reported in June 2026. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . Flentge Expires 29 April 2027 [Page 10] Internet-Draft Compressed Bundle Status Reporting October 2026 [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, . [I-D.flentge-dtn-bundle-sequence-identification] Flentge, F., "Bundle Sequence Identification for the Bundle Protocol Version 7", Work in Progress, Internet- Draft, draft-flentge-dtn-bundle-sequence-identification- 00, 6 October 2026, . 14.2. Informative References [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [CCSDS-734.6-O-1] Consultative Committee for Space Data Systems, "Custody Transfer and Compressed Bundle Status Reporting, Experimental Specification", CCSDS 734.6-O-1, June 2026, . [I-D.flentge-dtn-bpv7-custody-transfer] Flentge, F., "Custody Transfer for Bundle Protocol Version 7", Work in Progress, Internet-Draft, draft-flentge-dtn- bpv7-custody-transfer-00, 6 October 2026, . Appendix A. Acknowledgements The author would like to acknowledge the substantial technical contributions of Aida Manole, Alice LeBihan, and Yanik Jeck to the development, review, discussion, and refinement of the mechanisms specified in this document. Their contributions to the corresponding CCSDS work significantly influenced the design and maturation of this specification. Author's Address Flentge Expires 29 April 2027 [Page 11] Internet-Draft Compressed Bundle Status Reporting October 2026 Felix Flentge European Space Agency Email: felix.flentge@esa.int Flentge Expires 29 April 2027 [Page 12]