Compressed Bundle Status Reporting for Bundle Protocol Version 7

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.¶

Table of Contents

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.¶

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.¶

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.¶

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.¶

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].¶

;CREB
$extension-block /= extension-block-use<14, embedded-cbor<creb-data>>

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.¶

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

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