Summary

  • RFC 9171 makes reception, forwarding, local delivery, deletion and reporting distinct Bundle Protocol states; a report describes the state asserted by its reporting node.
  • BPv7 does not itself ensure end-to-end delivery, and custody transfer is no longer a base-protocol state. Receipt therefore cannot prove custody, application processing, authority or an external result.

Delay-tolerant networking is built for places where the usual conversational assumptions of networking do not hold. Connectivity may be intermittent, delays large, links one-way and the next contact uncertain. Its Bundle Protocol, BPv7, carries a unit of application data together with the protocol material needed to make that data usable when it can be delivered. In such an environment, an honest record needs more verbs than “sent” and “done”.

RFC 9171 supplies those verbs with unusual care. It distinguishes a transmission—an attempt by a Bundle Protocol Agent, or BPA, to cause copies to be delivered—from forwarding, the invocation of one or more convergence-layer adapters in a sustained effort to cause a copy to be received by another node. It defines delivery still more narrowly: the payload and relevant metadata have been presented to the application agent at a node, subject to a local registration. It separately defines deletion, discarding and the retention constraints that can keep a bundle from being discarded.

Those definitions are not editorial decoration. They are the evidence model. A forwarded bundle is not necessarily a received bundle. A received bundle is not necessarily locally deliverable. A locally delivered payload is not necessarily processed by the application. A report about any one of those states is not automatically received by the party that needs to act on it. Combining them into a single “delivered” label makes a system sound more certain while erasing the point at which responsibility changes hands.

The reception procedure makes the first boundary visible. When a BPA receives a bundle from another node, it adds a “Dispatch pending” retention constraint. If the sender requested a reception report and status reporting is enabled, the BPA should generate a report to the bundle’s report-to endpoint. That is a useful observation: this node has begun the specified processing of a received bundle.

It is not the end of that processing. The same procedure calls for checks of attached CRCs. A malformed bundle or one whose attached CRC does not match must be deleted, with remaining reception steps skipped. Unsupported extension blocks can also yield a status report and then, depending on their controls, cause deletion or removal. In other words, the event “a bundle reception report was generated” cannot be silently expanded into “a conforming bundle was retained, forwarded or delivered”. The protocol deliberately leaves room for those later outcomes to differ.

Forwarding has a different scope. The BPA selects another node or nodes and a convergence-layer adapter, then asks the adapter to send the bundle. Completion of the relevant data-sending procedures can be treated as successful forwarding, but that determination is implementation-specific; when forwarding does not succeed, the BPA may try again, subject to local configuration. A requested forwarding report is a report of that forwarding state. It is not a receipt from the next node, a proof that a route will continue to work, or a declaration that the destination has been reached.

The distinction becomes sharper at the destination. RFC 9171 says that local delivery depends on the registration associated with the destination endpoint. Fragments may first need reassembly. A passive registration or an implementation-specific delivery failure can defer delivery or abandon it. Even after local delivery, a bundle delivery status report—if requested and if reporting is enabled—states only that the payload has been delivered to the application agent. The RFC says expressly that it does not state that the application agent processed the payload.

That sentence should matter to anyone designing a control around machine-to-machine workflow. An application agent could validate, queue, reject, defer, transform or ignore its payload according to its own rules. The protocol state does not reveal which of those happened. It does not identify the business owner of the application, establish that an authorised person reviewed a result, or say that an irreversible instruction was executed. If those propositions matter, the application and the decision system must retain their own records.

Status reports are helpful but are not an all-seeing audit trail. RFC 9171 requires their generation to be disabled by default because a large number of requests can generate excessive traffic. Even once reporting is enabled, the decision to generate a requested report is left to the BPA. The status time, if carried, is time reported by that node’s local clock and is an implementation matter. A report is therefore a bounded assertion made by one node, carried as another bundle to a report-to endpoint. It is not a global, lossless chronology and not proof that its intended reader received it.

The historical custody contrast is just as important. The experimental RFC 5050 defined custody acceptance and custody signals. RFC 9171’s own registry table identifies the corresponding request flags as version-6 values, and its Appendix A says custody transfer moved to the Bundle-in-Bundle Encapsulation specification. Base BPv7 preserves other valuable tools—retention constraints, forwarding state, local delivery, reports and extension points—but it does not make receipt synonymous with taking custody.

An operator who needs a durable retention undertaking must name the mechanism and its conditions rather than obtaining that conclusion from a reception bit.

RFC 9171 is explicit about the largest limit: the Bundle Protocol itself does not ensure delivery to a destination. Reliable convergence-layer protocols can reduce loss between neighbours; end-to-end delivery assurance needs BP extensions and/or application-layer mechanisms. This is not a flaw waiting to be discovered. It is a clean allocation of responsibility. The protocol describes what a BPA did with a bundle at a defined point. It does not pretend to decide what later systems, people or institutions did with the information.

For leadership teams, the practical question is not whether to distrust a receipt. It is whether the record says what it actually knows. Keep the receiving node’s event distinct from forwarding, local delivery, application processing, acknowledgement, business approval and external execution. Record who asserts each fact, what protocol or application rule made the assertion possible, where the record is sent, which time source applies and what would count as a failure or expiry. This makes the control more useful, not less.

A narrowly true record can be joined to another narrowly true record; a falsely comprehensive green light cannot be audited back into honesty.

Lu Heng’s distinction between a representation, a local decision and running reality is a useful editorial discipline here. A BP status report is a representation of a scoped protocol state. It should be trusted for that state, not promoted into a declaration of authority or success. Running systems gain resilience when they preserve the boundary between an event they observed and a consequence someone still has to choose and carry out.

Sources