RFC 9171: Bundle Protocol Version 7

3.1. Definitions

Bundle:

A bundle is a PDU of BP, so named because negotiation of the parameters of a data exchange may be impractical in a delay-tolerant network: it is often better practice to "bundle" with a unit of application data all metadata that might be needed in order to make the data immediately usable when delivered to the application. Each bundle comprises a sequence of two or more "blocks" of protocol data, which serve various purposes.¶

Block:

A Bundle Protocol block is one of the protocol data structures that together constitute a well-formed bundle.¶

Application Data Unit:

An application data unit (ADU) is the unit of data whose conveyance to the bundle's destination is the purpose for the transmission of some bundle that is not a fragment (as defined below).¶

Bundle payload:

A bundle payload (or simply "payload") is the content of the bundle's payload block. The terms "bundle content", "bundle payload", and "payload" are used interchangeably in this document. For a bundle that is not a fragment (as defined below), the payload is an ADU.¶

Partial payload:

A partial payload is a payload that comprises either the first N bytes or the last N bytes of some other payload of length M, such that 0 < N < M. Note that every partial payload is a payload and therefore can be further subdivided into partial payloads.¶

Fragment:

A fragment, a.k.a. "fragmentary bundle", is a bundle whose payload block contains a partial payload.¶

Bundle node:

A bundle node (or, in the context of this document, simply a "node") is any entity that can send and/or receive bundles. Each bundle node has three conceptual components, defined below, as shown in Figure 2: a "Bundle Protocol Agent", a set of zero or more "convergence-layer adapters", and an "application agent". ("CL1 PDUs" are the PDUs of the convergence-layer protocol used in network 1.)¶

+-----------------------------------------------------------+
|Node                                                       |
|                                                           |
| +-------------------------------------------------------+ |
| |Application Agent                                      | |
| |                                                       | |
| | +--------------------------+ +----------------------+ | |
| | |Administrative element    | |Application-specific  | | |
| | |                          | |element               | | |
| | |                          | |                      | | |
| | +--------------------------+ +----------------------+ | |
| |                ^                          ^           | |
| |           Admin|records        Application|data       | |
| |                |                          |           | |
| +----------------v--------------------------v-----------+ |
|                               ^                           |
|                               | ADUs                      |
|                               |                           |
| +-----------------------------v-------------------------+ |
| |Bundle Protocol Agent                                  | |
| |                                                       | |
| |                                                       | |
| +-------------------------------------------------------+ |
|        ^                 ^                        ^       |
|        | Bundles         | Bundles        Bundles |       |
|        |                 |                        |       |
| +------v-----+     +-----v------+           +-----v-----+ |
| |CLA 1       |     |CLA 2       |           |CLA n      | |
| |            |     |            |   . . .   |           | |
| |            |     |            |           |           | |
+-+------------+-----+------------+-----------+-----------+-+
         ^                 ^                        ^
      CL1|PDUs          CL2|PDUs                 CLn|PDUs
         |                 |                        |
  +------v-----+     +-----v------+           +-----v-----+
   Network 1          Network 2                Network n

Bundle Protocol Agent:

The Bundle Protocol Agent (BPA) of a node is the node component that offers the BP services and executes the procedures of the Bundle Protocol.¶

Convergence-layer adapter:

A convergence-layer adapter (CLA) is a node component that sends and receives bundles on behalf of the BPA, utilizing the services of some "integrated" protocol stack that is supported in one of the networks within which the node is functionally located.¶

Application agent:

The application agent (AA) of a node is the node component that utilizes the BP services to effect communication for some user purpose. The application agent in turn has two elements: an administrative element and an application-specific element.¶

Application-specific element:

The application-specific element of an AA is the node component that constructs, requests transmission of, accepts delivery of, and processes units of user application data.¶

Administrative element:

The administrative element of an AA is the node component that constructs and requests transmission of administrative records (defined below), including status reports, and accepts delivery of and processes any administrative records that the node receives.¶

Administrative record:

A BP administrative record is an ADU that is exchanged between the administrative elements of nodes' application agents for some BP administrative purpose. The only administrative record defined in this specification is the status report, discussed later.¶

Bundle endpoint:

A bundle endpoint (or simply "endpoint") is a set of zero or more bundle nodes that all identify themselves for BP purposes by some common identifier, called a "bundle endpoint ID" (or, in this document, simply "endpoint ID"); endpoint IDs are described in detail in Section 4.2.5.1.¶

Singleton endpoint:

A singleton endpoint is an endpoint that always contains exactly one member.¶

Registration:

A registration is the state machine characterizing a given node's membership in a given endpoint. Any single registration has an associated delivery failure action as defined below and must at any time be in one of two states: Active or Passive. Registrations are local; information about a node's registrations is not expected to be available at other nodes, and the Bundle Protocol does not include a mechanism for distributing information about registrations.¶

Delivery:

A bundle is considered to have been delivered at a node subject to a registration as soon as the ADU that is the payload of the bundle, together with any relevant metadata (an implementation matter), has been presented to the node's application agent in a manner consistent with the state of that registration.¶

Deliverability:

A bundle is considered "deliverable" subject to a registration if and only if (a) the bundle's destination endpoint is the endpoint with which the registration is associated, (b) the bundle has not yet been delivered subject to this registration, and (c) the bundle has not yet been "abandoned" (as defined below) subject to this registration.¶

Abandonment:

To abandon a bundle subject to some registration is to assert that the bundle is not deliverable subject to that registration.¶

Delivery failure action:

The delivery failure action of a registration is the action that is to be taken when a bundle that is "deliverable" subject to that registration is received at a time when the registration is in the Passive state.¶

Destination:

The destination of a bundle is the endpoint comprising the node(s) at which the bundle is to be delivered (as defined above).¶

Transmission:

A transmission is an attempt by a node's BPA to cause copies of a bundle to be delivered to one or more of the nodes that are members of some endpoint (the bundle's destination) in response to a transmission request issued by the node's application agent.¶

Forwarding:

To forward a bundle to a node is to invoke the services of one or more CLAs in a sustained effort to cause a copy of the bundle to be received by that node.¶

Discarding:

To discard a bundle is to cease all operations on the bundle and functionally erase all references to it. The specific procedures by which this is accomplished are an implementation matter.¶

Retention constraint:

A retention constraint is an element of the state of a bundle that prevents the bundle from being discarded. That is, a bundle cannot be discarded while it has any retention constraints.¶

Deletion:

To delete a bundle is to remove unconditionally all of the bundle's retention constraints, enabling the bundle to be discarded.¶

3.2. Discussion of BP Concepts

Multiple instances of the same bundle (the same unit of DTN protocol data) might exist concurrently in different parts of a network -- possibly differing in some blocks -- in the memory local to one or more bundle nodes and/or in transit between nodes. In the context of the operation of a bundle node, a bundle is an instance (copy), in that node's local memory, of some bundle that is in the network.¶

The payload for a bundle forwarded in response to a bundle transmission request is the ADU whose location is provided as a parameter to that request. The payload for a bundle forwarded in response to reception of a bundle is the payload of the received bundle.¶

In the most familiar case, a bundle node is instantiated as a single process running on a general-purpose computer, but in general the definition is meant to be broader: a bundle node might alternatively be a thread, an object in an object-oriented operating system, a special-purpose hardware device, etc.¶

The manner in which the functions of the BPA are performed is wholly an implementation matter. For example, BPA functionality might be coded into each node individually; it might be implemented as a shared library that is used in common by any number of bundle nodes on a single computer; it might be implemented as a daemon whose services are invoked via inter-process or network communication by any number of bundle nodes on one or more computers; it might be implemented in hardware.¶

Every CLA implements its own thin layer of protocol, interposed between BP and the (usually "top") protocol(s) of the underlying integrated protocol stack; this "CL protocol" may only serve to multiplex and demultiplex bundles to and from the underlying integrated protocol, or it may offer additional CL-specific functionality. The manner in which a CLA sends and receives bundles, as well as the definitions of CLAs and CL protocols, are beyond the scope of this specification.¶

Note that the administrative element of a node's application agent may itself, in some cases, function as a CLA. That is, outgoing bundles may be "tunneled" through encapsulating bundles:¶

The purposes for which this technique may be useful (such as cross-domain security) are beyond the scope of this specification.¶

The only interface between the BPA and the application-specific element of the AA is the BP service interface. But between the BPA and the administrative element of the AA there is a (conceptual) private control interface in addition to the BP service interface. This private control interface enables the BPA and the administrative element of the AA to direct each other to take action under specific circumstances.¶

In the case of a node that serves simply as a BP "router", the AA may have no application-specific element at all. The application-specific elements of other nodes' AAs may perform arbitrarily complex application functions, perhaps even offering multiplexed DTN communication services to a number of other applications. As with the BPA, the manner in which the AA performs its functions is wholly an implementation matter.¶

Singletons are the most familiar sort of endpoint, but in general the endpoint notion is meant to be broader. For example, the nodes in a sensor network might constitute a set of bundle nodes that are all registered in a single common endpoint and will all receive any data delivered at that endpoint. Note too that any given bundle node might be registered in multiple bundle endpoints and receive all data delivered at each of those endpoints.¶

Recall that every node, by definition, includes an application agent, which in turn includes an administrative element, which exchanges administrative records with the administrative elements of other nodes. As such, every node is permanently, structurally registered in the singleton endpoint at which administrative records received from other nodes are delivered. Registration in no other endpoint can ever be assumed to be permanent. This endpoint, termed the node's "administrative endpoint", is therefore uniquely and permanently associated with the node, and for this reason the ID of a node's administrative endpoint may always serve as the "node ID" (see Section 4.2.5.2) of the node.¶

The destination of every bundle is an endpoint, which may or may not be singleton. The source of every bundle is a node, identified by node ID. Note, though, that the source node ID asserted in a given bundle may be the null endpoint ID (as described later) rather than the ID of the source node; bundles for which the asserted source node ID is the null endpoint ID are termed "anonymous" bundles.¶

Any number of transmissions may be concurrently undertaken by the BPA of a given node.¶

When the BPA of a node determines that it must forward a bundle either to a node that is a member of the bundle's destination endpoint or to some intermediate forwarding node, the BPA invokes the services of one or more CLAs in a sustained effort to cause a copy of the bundle to be received by that node.¶

Upon reception, the processing of a bundle depends on whether or not the receiving node is registered in the bundle's destination endpoint. If it is, and if the payload of the bundle is non-fragmentary (possibly as a result of successful payload reassembly from fragmentary payloads, including the original payload of the newly received bundle), then the bundle is normally delivered to the node's application agent subject to the registration characterizing the node's membership in the destination endpoint.¶

The Bundle Protocol itself does not ensure delivery of a bundle to its destination. Data loss along the path to the destination node can be minimized by utilizing reliable convergence-layer protocols between neighbors on all segments of the end-to-end path; however, for end-to-end bundle delivery assurance it will be necessary to develop extensions to the Bundle Protocol and/or application-layer mechanisms.¶

The Bundle Protocol is designed for extensibility. Bundle Protocol extensions, documented elsewhere, may extend this specification by defining additional:¶

3.3. Services Offered by Bundle Protocol Agents

The BPA of each node is expected to provide the following services to the node's application agent:¶

Note that the details of registration functionality are an implementation matter and are beyond the scope of this specification.¶

4.1. Bundle Structure

The format of bundles SHALL conform to the Concise Binary Object Representation (CBOR) [RFC8949].¶

Cryptographic verification of a block is possible only if the sequence of octets on which the verifying node computes its hash -- the canonicalized representation of the block -- is identical to the sequence of octets on which the hash declared for that block was computed. To ensure that blocks are always in canonical representation when they are transmitted and received, the CBOR encodings of the values of all fields in all blocks MUST conform to the core deterministic encoding requirements as specified in [RFC8949], except that indefinite-length items are not prohibited.¶

Each bundle SHALL be a concatenated sequence of at least two blocks, represented as a CBOR indefinite-length array. The first block in the sequence (the first item of the array) MUST be a primary bundle block in CBOR encoding as described below; the bundle MUST have exactly one primary bundle block. The primary block MUST be followed by one or more canonical bundle blocks (additional array items) in CBOR encoding as described in Section 4.3.2. Every block following the primary block SHALL be the CBOR encoding of a canonical block. The last such block MUST be a payload block; the bundle MUST have exactly one payload block. The payload block SHALL be followed by a CBOR "break" stop code, terminating the array.¶

Associated with each block of a bundle is a block number. The block number uniquely identifies the block within the bundle, enabling blocks (notably Bundle Protocol Security blocks) to reference other blocks in the same bundle without ambiguity. The block number of the primary block is implicitly zero; the block numbers of all other blocks are explicitly stated in block headers as noted below. Block numbering is unrelated to the order in which blocks are sequenced in the bundle. The block number of the payload block is always 1.¶

An implementation of the Bundle Protocol MAY discard any sequence of bytes that does not conform to the Bundle Protocol specification.¶

An implementation of the Bundle Protocol MAY accept a sequence of bytes that does not conform to the Bundle Protocol specification (e.g., one that represents data elements in fixed-length arrays rather than indefinite-length arrays) and transform it into conformant BP structure before processing it. Procedures for accomplishing such a transformation are beyond the scope of this specification.¶

4.2. BP Fundamental Data Structures

dtn-uri = "dtn:" ("none" / dtn-hier-part)

dtn-hier-part = "//" node-name name-delim demux ; a path-rootless

node-name = reg-name

name-delim = "/"

demux = *VCHAR

ipn-uri = "ipn:" ipn-hier-part

ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless

node-nbr = 1*DIGIT

nbr-delim = "."

service-nbr = 1*DIGIT

4.3. Block Structures

This section describes the primary block in detail and non-primary blocks in general. Rules for processing these blocks appear in Section 5.¶

Note that supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may require that BP implementations conforming to those protocols construct and process additional blocks.¶

4.4. Extension Blocks

"Extension blocks" are all blocks other than the primary and payload blocks. Three types of extension blocks are defined below. All implementations of the Bundle Protocol specification (the present document) MUST include procedures for recognizing, parsing, and acting on, but not necessarily producing, these types of extension blocks.¶

The specifications for additional types of extension blocks must indicate whether or not BP implementations conforming to those specifications must recognize, parse, act on, and/or produce blocks of those types. As not all nodes will necessarily instantiate BP implementations that conform to those additional specifications, it is possible for a node to receive a bundle that includes extension blocks that the node cannot process. The values of the block processing control flags indicate the action to be taken by the BPA when this is the case.¶

No mandated procedure in this specification is unconditionally dependent on the absence or presence of any extension block. Therefore, any BPA MAY insert or remove any extension block in any bundle, subject to all mandates in the Bundle Protocol specification and all extension block specifications to which the node's BP implementation conforms. Note that removal of an extension block will probably disable one or more elements of bundle processing that were intended by the BPA that inserted that block. In particular, note that removal of an extension block that is one of the targets of a BPSec security block may render the bundle unverifiable.¶

The following extension blocks are defined in the current document.¶

5.1. Generation of Administrative Records

All transmission of bundles is in response to bundle transmission requests presented by nodes' application agents. When required to "generate" an administrative record (such as a bundle status report), the BPA itself is responsible for causing a new bundle to be transmitted, conveying that record. In concept, the BPA discharges this responsibility by directing the administrative element of the node's application agent to construct the record and request its transmission as detailed in Section 6. In practice, the manner in which administrative record generation is accomplished is an implementation matter, provided the constraints noted in Section 6 are observed.¶

Status reports are relatively small bundles. Moreover, even when the generation of status reports is enabled, the decision on whether or not to generate a requested status report is left to the discretion of the BPA. Nonetheless, note that requesting status reports for any single bundle might easily result in the generation of (1 + (2 *(N-1))) status report bundles, where N is the number of nodes on the path from the bundle's source to its destination, inclusive. That is, the requesting of status reports for large numbers of bundles could result in an unacceptable increase in the bundle traffic in the network. For this reason, the generation of status reports MUST be disabled by default and enabled only when the risk of excessive network traffic is deemed acceptable. Mechanisms that could assist in assessing and mitigating this risk, such as pre-placed agreements authorizing the generation of status reports under specified circumstances, are beyond the scope of this specification.¶

Notes on administrative record terminology:¶

5.2. Bundle Transmission

The steps in processing a bundle transmission request are as follows:¶

Step 1:

Transmission of the bundle is initiated. An outbound bundle MUST be created per the parameters of the bundle transmission request, with the retention constraint "Dispatch pending". The source node ID of the bundle MUST be either (a) the null endpoint ID, indicating that the source of the bundle is anonymous or (b) the EID of a singleton endpoint whose only member is the node of which the BPA is a component.¶

Step 2:

Processing proceeds from Step 1 of Section 5.4.¶

5.3. Bundle Dispatching

(Note that this procedure is initiated only following completion of Step 4 of Section 5.6.)¶

The steps in dispatching a bundle are as follows:¶

Step 1:

If the bundle's destination endpoint is an endpoint of which the node is a member, the Bundle Delivery procedure defined in Section 5.7 MUST be followed and, for the purposes of all subsequent processing of this bundle at this node, the node's membership in the bundle's destination endpoint SHALL be disavowed; specifically, even though the node is a member of the bundle's destination endpoint, the node SHALL NOT undertake to forward the bundle to itself in the course of performing the procedure described in Section 5.4.¶

Step 2:

Processing proceeds from Step 1 of Section 5.4.¶

5.4. Bundle Forwarding

The steps in forwarding a bundle are as follows:¶

Step 1:

The retention constraint "Forward pending" MUST be added to the bundle, and the bundle's "Dispatch pending" retention constraint MUST be removed.¶

Step 2:

The BPA MUST determine whether or not forwarding is contraindicated (that is, rendered inadvisable) for any of the reasons listed in the IANA "Bundle Status Report Reason Codes" registry (see Section 9.5), whose initial contents are listed in Table 1. In particular:¶

• The BPA MAY choose to either forward the bundle directly to its destination node(s) (if possible) or forward the bundle to some other node(s) for further forwarding. The manner in which this decision is made may depend on the scheme name in the destination endpoint ID and/or on other state but in any case is beyond the scope of this document; one possible mechanism is described in [SABR]. If the BPA elects to forward the bundle to some other node(s) for further forwarding but finds it impossible to select any node(s) to forward the bundle to, then forwarding is contraindicated.¶
• Provided the BPA succeeded in selecting the node or nodes to forward the bundle to, the BPA MUST subsequently select the CLA(s) whose services will enable the node to send the bundle to those nodes. The manner in which specific appropriate CLAs are selected is beyond the scope of this document; the TCP CLA [TCPCL] MUST be implemented when some or all of the bundles forwarded by the BPA must be forwarded via the Internet but may not be appropriate for the forwarding of any particular bundle. If the agent finds it impossible to select any appropriate CLA(s) to use in forwarding this bundle, then forwarding is contraindicated.¶

Step 3:

If forwarding of the bundle is determined to be contraindicated for any of the reasons listed in the IANA "Bundle Status Report Reason Codes" registry (see Section 9.5), then the Forwarding Contraindicated procedure defined in Section 5.4.1 MUST be followed; the remaining steps of this Bundle Forwarding procedure are skipped at this time.¶

Step 4:

For each node selected for forwarding, the BPA MUST invoke the services of the selected CLA(s) in order to effect the sending of the bundle to that node. Determining the time at which the BPA invokes CLA services is a BPA implementation matter. Determining the time at which each CLA subsequently responds to this service invocation by sending the bundle is a CLA implementation matter. Note that:¶

• If the bundle has a Previous Node Block, as defined in Section 4.4.1, then that block MUST be removed from the bundle before the bundle is forwarded.¶
• If the BPA is configured to attach Previous Node Blocks to forwarded bundles, then a Previous Node Block containing the node ID of the forwarding node MUST be inserted into the bundle before the bundle is forwarded.¶
• If the bundle has a Bundle Age Block, as defined in Section 4.4.2, then at the last possible moment before the CLA initiates conveyance of the bundle via the CL protocol the bundle age value MUST be increased by the difference between the current time and the time at which the bundle was received (or, if the local node is the source of the bundle, created).¶

Step 5:

When all selected CLAs have informed the BPA that they have concluded their data-sending procedures with regard to this bundle, processing may depend on the results of those procedures.¶

If completion of the data-sending procedures by all selected CLAs has not resulted in successful forwarding of the bundle (an implementation-specific determination that is beyond the scope of this specification), then the BPA MAY choose (in an implementation-specific manner, again beyond the scope of this specification) to initiate another attempt to forward the bundle. In that event, processing proceeds from Step 4. The minimum number of times a given node will initiate another forwarding attempt for any single bundle in this event (a number that may be zero) is a node configuration parameter that must be exposed to other nodes in the network to the extent that this is required by the operating environment.¶

If completion of the data-sending procedures by all selected CLAs HAS resulted in successful forwarding of the bundle, or if it has not but the BPA does not choose to initiate another attempt to forward the bundle, then:¶

5.5. Bundle Expiration

A bundle expires when the bundle's age exceeds its lifetime as specified in the primary bundle block or as overridden by the BPA. Bundle age MAY be determined by subtracting the bundle's creation timestamp time from the current time if (a) that timestamp time is not zero and (b) the local node's clock is known to be accurate; otherwise, bundle age MUST be obtained from the Bundle Age extension block. Bundle expiration MAY occur at any point in the processing of a bundle. When a bundle expires, the BPA MUST delete the bundle for the reason "Lifetime expired" (when the expired lifetime is the lifetime as specified in the primary block) or "Traffic pared" (when the expired lifetime is a lifetime override as imposed by the BPA): the Bundle Deletion procedure defined in Section 5.10 MUST be followed.¶

5.6. Bundle Reception

The steps in processing a bundle that has been received from another node are as follows:¶

Step 1:

The retention constraint "Dispatch pending" MUST be added to the bundle.¶

Step 2:

If the "request reporting of bundle reception" flag in the bundle's status report request field is set to 1 and status reporting is enabled, then a bundle reception status report with reason code "No additional information" SHOULD be generated, destined for the bundle's report-to endpoint ID.¶

Step 3:

CRCs SHOULD be computed for every block of the bundle that has an attached CRC. If any block of the bundle is malformed according to this specification (including syntactically invalid CBOR), or if any block has an attached CRC and the CRC computed for this block upon reception differs from that attached CRC, then the BPA MUST delete the bundle for the reason "Block unintelligible". The Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped.¶

Step 4:

For each block in the bundle that is an extension block that the BPA cannot process:¶

• If the block processing control flags in that block indicate that a status report is requested in this event and if status reporting is enabled, then a bundle reception status report with reason code "Block unsupported" SHOULD be generated, destined for the bundle's report-to endpoint ID.¶
• If the block processing control flags in that block indicate that the bundle must be deleted in this event, then the BPA MUST delete the bundle for the reason "Block unsupported"; the Bundle Deletion procedure defined in Section 5.10 MUST be followed, and all remaining steps of the Bundle Reception procedure MUST be skipped.¶
• If the block processing control flags in that block do NOT indicate that the bundle must be deleted in this event but do indicate that the block must be discarded, then the BPA MUST remove this block from the bundle.¶
• If the block processing control flags in that block neither indicate that the bundle must be deleted nor indicate that the block must be discarded, then processing continues with the next extension block that the BPA cannot process, if any; otherwise, processing proceeds from Step 5.¶

Step 5:

Processing proceeds from Step 1 of Section 5.3.¶

5.7. Local Bundle Delivery

The steps in processing a bundle that is destined for an endpoint of which this node is a member are as follows:¶

Step 1:

If the received bundle is a fragment, the ADU Reassembly procedure described in Section 5.9 MUST be followed. If this procedure results in reassembly of the entire original ADU, processing of the fragmentary bundle whose payload has been replaced by the reassembled ADU (whether this bundle or a previously received fragment) proceeds from Step 2; otherwise, the retention constraint "Reassembly pending" MUST be added to the bundle, and all remaining steps of this procedure MUST be skipped.¶

Step 2:

Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle:¶

• An additional implementation-specific delivery deferral procedure MAY optionally be associated with the registration.¶
• If the registration is in the Active state, then the bundle MUST be delivered automatically as soon as it is the next bundle that is due for delivery according to the BPA's bundle delivery scheduling policy (an implementation matter).¶

• If the registration is in the Passive state, or if delivery of the bundle fails for some implementation-specific reason, then the registration's delivery failure action MUST be taken. The delivery failure action MUST be one of the following:¶

  • Defer delivery of the bundle subject to this registration until (a) this bundle is the least recently received of all bundles currently deliverable subject to this registration and (b) either the registration is polled or the registration is in the Active state, and also perform any additional delivery deferral procedure associated with the registration, or¶
  • Abandon delivery of the bundle subject to this registration (as defined in Section 3.1).¶

Step 3:

As soon as the bundle has been delivered, if the "request reporting of bundle delivery" flag in the bundle's status report request field is set to 1 and bundle status reporting is enabled, then a bundle delivery status report SHOULD be generated, destined for the bundle's report-to endpoint ID. Note that this status report only states that the payload has been delivered to the application agent, not that the application agent has processed that payload.¶

5.8. Bundle Fragmentation

It may at times be advantageous for BPAs to reduce the sizes of bundles in order to forward them. This might be the case, for example, if a node to which a bundle is to be forwarded is accessible only via intermittent contacts and no upcoming contact is long enough to enable the forwarding of the entire bundle.¶

The size of a bundle can be reduced by "fragmenting" the bundle. To fragment a bundle whose payload is of size M is to replace it with two "fragments" -- new bundles with the same source node ID and creation timestamp as the original bundle -- whose payloads MUST be the first N and the last (M - N) bytes of the original bundle's payload, where 0 < N < M.¶

Note that fragments are bundles and therefore may themselves be fragmented, so multiple episodes of fragmentation may in effect replace the original bundle with more than two fragments. (However, there is only one "level" of fragmentation, as in IP fragmentation.)¶

Any bundle whose primary block's bundle processing control flags do NOT indicate that it must not be fragmented MAY be fragmented at any time, for any purpose, at the discretion of the BPA. NOTE, however, that some combinations of bundle fragmentation, replication, and routing might result in unexpected traffic patterns.¶

Fragmentation SHALL be constrained as follows:¶

5.9. Application Data Unit Reassembly

Note that the Bundle Fragmentation procedure described in Section 5.8 may result in the replacement of a single original bundle with an arbitrarily large number of fragmentary bundles. In order to be delivered at a destination node, the original bundle's payload must be reassembled from the payloads of those fragments.¶

The "material extents" of a received fragment's payload are all continuous sequences of bytes in that payload that do not overlap with the material extents of the payloads of any previously received fragments with the same source node ID and creation timestamp. If the concatenation -- as informed by fragment offsets and payload lengths -- of the material extents of the payloads of this fragment and all previously received fragments with the same source node ID and creation timestamp as this fragment forms a continuous byte array whose length is equal to the total application data unit length noted in the fragment's primary block, then:¶

Note: Reassembly of ADUs from fragments occurs at the nodes that are members of destination endpoints as necessary; an ADU MAY also be reassembled at some other node on the path to the destination.¶

5.10. Bundle Deletion

The steps in deleting a bundle are as follows:¶

Step 1:

If the "request reporting of bundle deletion" flag in the bundle's status report request field is set to 1 and if status reporting is enabled, then a bundle deletion status report citing the reason for deletion SHOULD be generated, destined for the bundle's report-to endpoint ID.¶

Step 2:

All of the bundle's retention constraints MUST be removed.¶

5.11. Discarding a Bundle

As soon as a bundle has no remaining retention constraints, it MAY be discarded, thereby releasing any persistent storage that may have been allocated to it.¶

5.12. Canceling a Transmission

When requested to cancel a specified transmission, where the bundle created upon initiation of the indicated transmission has not yet been discarded, the BPA MUST delete that bundle for the reason "Transmission canceled". For this purpose, the procedure defined in Section 5.10 MUST be followed.¶

6.1. Administrative Records

Administrative records are standard ADUs that are used in providing some of the features of the Bundle Protocol. Bundle Protocol administrative record types are registered in the IANA "Bundle Administrative Record Types" registry [RFC5050]; of these, only administrative record type 1, "Bundle status report", is defined for BPv7 at this time. Note that additional types of administrative records may be defined by supplementary DTN protocol specification documents.¶

Every administrative record consists of:¶

Each BP administrative record SHALL be represented as a CBOR array comprising two items.¶

The first item of the array SHALL be a record type code, which SHALL be represented as a CBOR unsigned integer.¶

The second element of this array SHALL be the applicable CBOR encoding of the content of the record. Details of the CBOR encoding of administrative record type 1 are provided below. Details of the CBOR encoding of other types of administrative records are included in the specifications defining those records.¶

6.2. Generation of Administrative Records

Whenever the application agent's administrative element is directed by the BPA to generate an administrative record, the following procedure must be followed:¶

Step 1:

The administrative record must be constructed. If the administrative record references a bundle and the referenced bundle is a fragment, the administrative record MUST contain the fragment offset and fragment length.¶

Step 2:

A request for transmission of a bundle whose payload is this administrative record MUST be presented to the BPA.¶

7.1. The Convergence Layer

The successful operation of the end-to-end Bundle Protocol depends on the operation of underlying protocols at what is termed the "convergence layer"; these protocols accomplish communication between nodes. A wide variety of protocols may serve this purpose, so long as each CLA provides a defined minimal set of services to the BPA. This convergence-layer service specification enumerates those services.¶

7.2. Summary of Convergence-Layer Services

Each CLA is expected to provide the following services to the BPA:¶

The convergence-layer service interface specified here is neither exhaustive nor exclusive. That is, supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may expect CLAs that serve BP implementations conforming to those protocols to provide additional services such as reporting on the transmission and/or reception progress of individual bundles (at completion and/or incrementally), retransmitting data that were lost in transit, discarding bundle-conveying data units that the convergence-layer protocol determines are corrupt or inauthentic, or reporting on the integrity and/or authenticity of delivered bundles.¶

In addition, the Bundle Protocol relies on the capabilities of protocols at the convergence layer to minimize congestion in the store-carry-forward overlay network. The potentially long round-trip times characterizing delay-tolerant networks are incompatible with end-to-end, reactive congestion-control mechanisms, so convergence-layer protocols MUST provide rate limiting or congestion control.¶

9.1. Bundle Block Types

The "Bundle Block Types" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the values. IANA has added the following values, as described in Section 4.3.1, to the "Bundle Block Types" registry with a value of "7" for the Bundle Protocol Version. IANA has set the Bundle Protocol Version to "6" or "6,7" for preexisting values in the "Bundle Block Types" registry, as shown below.¶

9.2. Primary Bundle Protocol Version

IANA has added the following value to the "Primary Bundle Protocol Version" subregistry in the "Bundle Protocol" registry.¶

Values 8-255 (rather than 7-255) are now Unassigned.¶

9.3. Bundle Processing Control Flags

The "Bundle Processing Control Flags" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the new values. IANA has added the following values, as described in Section 4.2.3, to the "Bundle Processing Control Flags" registry with a value of "7" for the Bundle Protocol Version. IANA has set the Bundle Protocol Version to the value "6" or "6,7" for preexisting values in the "Bundle Processing Control Flags" registry, as shown below.¶

9.4. Block Processing Control Flags

The "Block Processing Control Flags" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the related BP version. IANA has set the Bundle Protocol Version to the value "6" or "6,7" for preexisting values in the "Bundle Processing Control Flags" registry, as shown below.¶

9.5. Bundle Status Report Reason Codes

The "Bundle Status Report Reason Codes" subregistry in the "Bundle Protocol" registry has been augmented by adding a column identifying the version of the Bundle Protocol (Bundle Protocol Version) that applies to the new values. IANA has added the following values, as described in Section 6.1.1, to the "Bundle Status Report Reason Codes" registry with a value of "7" for the Bundle Protocol Version. IANA has set the Bundle Protocol Version to the value "6,7" for preexisting values in the "Bundle Status Report Reason Codes" registry, as shown below.¶

9.6. Bundle Protocol URI Scheme Types

The Bundle Protocol has a URI scheme type field -- an unsigned integer of indefinite length -- for which IANA has created, and will maintain, a new "Bundle Protocol URI Scheme Types" subregistry in the "Bundle Protocol" registry. The "Bundle Protocol URI Scheme Types" registry governs a namespace of unsigned integers. Initial values for the "Bundle Protocol URI Scheme Types" registry are given below.¶

The registration policy for this registry is Standards Action [RFC8126]. The allocation should only be granted for a Standards Track RFC approved by the IESG.¶

The range of values is provided as unsigned integers.¶

Each assignment consists of a URI scheme type name and its associated description, a reference to the document that defines the URI scheme, and a reference to the document that defines the use of this URI scheme in BP endpoint IDs (including the CBOR encoding of those endpoint IDs in transmitted bundles).¶

9.7. dtn URI Scheme

In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) registry, IANA has updated the registration of the URI scheme with the string "dtn" as the scheme name, as follows:¶

URI scheme name:

"dtn"¶

Status:

Permanent¶

Applications and/or protocols that use this URI scheme name:

The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).¶

Contact:

Scott Burleigh <sburleig.sb@gmail.com>¶

Change controller:

IETF (iesg@ietf.org)¶

Reference:

[RFC9171]¶

9.8. ipn URI Scheme

In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) registry, IANA has updated the registration of the URI scheme with the string "ipn" as the scheme name, originally documented in RFC 6260 [RFC6260], as follows.¶

URI scheme name:

"ipn"¶

Status:

Permanent¶

Applications and/or protocols that use this URI scheme name:

The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).¶

Contact:

Scott Burleigh <sburleig.sb@gmail.com>¶

Change controller:

IETF (iesg@ietf.org)¶

Reference:

[RFC9171]¶