• Ability to use physical motility for the movement of data.
• Ability to move the responsibility for error control from one node to another.
• Ability to cope with intermittent connectivity, including cases where the sender and receiver are not concurrently present in the network.
• Ability to take advantage of scheduled, predicted, and opportunistic connectivity, whether bidirectional or unidirectional, in addition to continuous connectivity.
• Late binding of overlay-network endpoint identifiers to underlying constituent network addresses.

+-----------+                                         +-----------+
|   BP app  |                                         |   BP app  |
+---------v-|   +->>>>>>>>>>v-+     +->>>>>>>>>>v-+   +-^---------+
|   BP    v |   | ^    BP   v |     | ^   BP    v |   | ^   BP    |
+---------v-+   +-^---------v-+     +-^---------v-+   +-^---------+
| T1      v |   + ^  T1/T2  v |     + ^  T2/T3  v |   | ^ T3      |
+---------v-+   +-^---------v-+     +-^---------v +   +-^---------+
| N1      v |   | ^  N1/N2  v |     | ^  N2/N3  v |   | ^ N3      |
+---------v-+   +-^---------v +     +-^---------v-+   +-^---------+
|         >>>>>>>>^         >>>>>>>>>>^         >>>>>>>>^         |
+-----------+   +-------------+     +-------------+   +-----------+
|                     |                     |                     |
|<---- A network ---->|                     |<---- A network ---->|
|                     |                     |                     |

• Operations in the convergence-layer adapters that bundle nodes use to transport data through specific types of internets. (However, the document does discuss the services that must be provided by each adapter at the convergence layer.)
• The bundle route computation algorithm.
• Mechanisms for populating the routing or forwarding information bases of bundle nodes.
• The mechanisms for securing bundles en route.
• The mechanisms for managing bundle nodes.

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.

• An outgoing bundle constitutes a byte array. This byte array may, like any other, be presented to the BPA as an ADU that is to be transmitted to some endpoint.
• The original bundle thus forms the payload of an encapsulating bundle that is forwarded using some other convergence-layer protocol(s).
• When the encapsulating bundle is received, its payload is delivered to the peer application agent administrative element, which then instructs the BPA to dispatch that original bundle in the usual way.

• blocks
• administrative records
• bundle processing control flags
• block processing control flags
• types of bundle status reports
• bundle status report reason codes
• mandates and constraints on processing that conformant BPAs must perform at specified points in the inbound and outbound bundle processing cycles

• commencing a registration (registering the node in an endpoint).
• terminating a registration.
• switching a registration between Active and Passive states.
• transmitting a bundle to an identified bundle endpoint.
• canceling a transmission.
• polling a registration that is in the Passive state.
• delivering a received bundle.

• 0 indicates "no Cyclic Redundancy Check (CRC) is present."
• 1 indicates "a standard X-25 CRC-16 is present." [CRC16]
• 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." [RFC 4960]

• The bundle is a fragment. (Boolean)
• The bundle's payload is an administrative record. (Boolean)
• The bundle must not be fragmented. (Boolean)
• Acknowledgment by the user application is requested. (Boolean)
• Status time is requested in all status reports. (Boolean)
• Flags requesting types of status reports (all Boolean):
  • Request reporting of bundle reception.
  • Request reporting of bundle forwarding.
  • Request reporting of bundle delivery.
  • Request reporting of bundle deletion.

Bit 0 (the low-order bit, 0x000001):

Bundle is a fragment.

Bit 1 (0x000002):

ADU is an administrative record.

Bit 2 (0x000004):

Bundle must not be fragmented.

Bit 3 (0x000008):

Reserved.

Bit 4 (0x000010):

Reserved.

Bit 5 (0x000020):

Acknowledgement by application is requested.

Bit 6 (0x000040):

Status time requested in reports.

Bit 7 (0x000080):

Reserved.

Bit 8 (0x000100):

Reserved.

Bit 9 (0x000200):

Reserved.

Bit 10 (0x000400):

Reserved.

Bit 11 (0x000800):

Reserved.

Bit 12 (0x001000):

Reserved.

Bit 13 (0x002000):

Reserved.

Bit 14 (0x004000):

Request reporting of bundle reception.

Bit 15 (0x008000):

Reserved.

Bit 16 (0x010000):

Request reporting of bundle forwarding.

Bit 17 (0x020000):

Request reporting of bundle delivery.

Bit 18 (0x040000):

Request reporting of bundle deletion.

Bits 19-20:

Reserved.

Bits 21-63:

Unassigned.

Bit 0 (the low-order bit, 0x01):

Block must be replicated in every fragment.

Bit 1 (0x02):

Transmit status report if block can't be processed.

Bit 2 (0x04):

Delete bundle if block can't be processed.

Bit 3 (0x08):

Reserved.

Bit 4 (0x10):

Discard block if it can't be processed.

Bit 5 (0x20):

Reserved.

Bit 6 (0x40):

Reserved.

Bits 7-63:

Unassigned.

Scheme syntax:

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC 5234].

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

Scheme semantics:

URIs of the dtn scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) as described in the present document.

Encoding considerations:

For transmission as a BP endpoint ID, the scheme-specific part of a URI of the dtn scheme SHALL be represented as a CBOR text string unless the EID's SSP is "none", in which case the SSP SHALL be represented as a CBOR unsigned integer with the value zero. For all other purposes, URIs of the dtn scheme are encoded exclusively in US-ASCII characters.

Interoperability considerations:

None.

Security considerations:

Reliability and consistency:

None of the BP endpoints identified by the URIs of the dtn scheme are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by Bundle Protocol Security [BPSEC], is required for this purpose.

Malicious construction:

Malicious construction of a conformant dtn-scheme URI is limited to the malicious selection of node names and the malicious selection of demux strings. That is, a maliciously constructed dtn-scheme URI could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way.

Back-end transcoding:

The limited expressiveness of URIs of the dtn scheme effectively eliminates the possibility of threat due to errors in back-end transcoding.

Rare IP address formats:

Not relevant, as IP addresses do not appear anywhere in conformant dtn-scheme URIs.

Sensitive information:

Because dtn-scheme URIs are used only to represent the identities of Bundle Protocol endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of dtn-scheme URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.

Semantic attacks:

The simplicity of dtn-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user.

Scheme syntax:

This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC 5234], including the core ABNF syntax rule for DIGIT defined by that specification.

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

Scheme semantics:

URIs of the ipn scheme are used as endpoint identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) as described in the present document.

Encoding considerations:

For transmission as a BP endpoint ID, the scheme-specific part of a URI of the ipn scheme SHALL be represented as a CBOR array comprising two items. The first item of this array SHALL be the EID's node number (a number that identifies the node) represented as a CBOR unsigned integer. The second item of this array SHALL be the EID's service number (a number that identifies some application service) represented as a CBOR unsigned integer. For all other purposes, URIs of the ipn scheme are encoded exclusively in US-ASCII characters.

Interoperability considerations:

None.

Security considerations:

Reliability and consistency:

None of the BP endpoints identified by the URIs of the ipn scheme are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by Bundle Protocol Security [BPSEC], is required for this purpose.

Malicious construction:

Malicious construction of a conformant ipn-scheme URI is limited to the malicious selection of node numbers and the malicious selection of service numbers. That is, a maliciously constructed ipn-scheme URI could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way.

Back-end transcoding:

The limited expressiveness of URIs of the ipn scheme effectively eliminates the possibility of threat due to errors in back-end transcoding.

Rare IP address formats:

Not relevant, as IP addresses do not appear anywhere in conformant ipn-scheme URIs.

Sensitive information:

Because ipn-scheme URIs are used only to represent the identities of Bundle Protocol endpoints, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of ipn-scheme URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.

Semantic attacks:

The simplicity of ipn-scheme URI syntax minimizes the possibility of misinterpretation of a URI by a human user.

• Every node is, by definition, permanently registered in the singleton endpoint at which administrative records are delivered to its application agent's administrative element, termed the node's "administrative endpoint".
• As such, the EID of a node's administrative endpoint SHALL uniquely identify that node.
• The EID of any singleton endpoint is allowed to serve as a "node ID" identifying the node that is the sole member of that endpoint.

Version:

An unsigned integer value indicating the version of the Bundle Protocol that constructed this block. The present document describes BPv7. This version number SHALL be represented as a CBOR unsigned integer item.

Bundle Processing Control Flags:

The bundle processing control flags are discussed in Section 4.2.3.

CRC Type:

CRC type codes are discussed in Section 4.2.1. The CRC type code for the primary block MAY be zero if the bundle contains a BPSec Block Integrity Block [BPSEC] whose target is the primary block; otherwise, the CRC type code for the primary block MUST be non-zero.

Destination EID:

The Destination EID field identifies the bundle endpoint that is the bundle's destination, i.e., the endpoint that contains the node(s) at which the bundle is to be delivered.

Source node ID:

The Source node ID field identifies the bundle node at which the bundle was initially transmitted, except that source node ID may be the null endpoint ID in the event that the bundle's source chooses to remain anonymous.

Report-to EID:

The Report-to EID field identifies the bundle endpoint to which status reports pertaining to the forwarding and delivery of this bundle are to be transmitted.

Creation Timestamp:

The creation timestamp comprises two unsigned integers that, together with the source node ID and (if the bundle is a fragment) the fragment offset and payload length, serve to identify the bundle. See Section 4.2.7 for the definition of this field.

Lifetime:

The Lifetime field is an unsigned integer that indicates the time at which the bundle's payload will no longer be useful, encoded as a number of milliseconds past the creation time. (For high-rate deployments with very brief disruptions, fine-grained expression of bundle lifetime may be useful.) When a bundle's age exceeds its lifetime, bundle nodes need no longer retain or forward the bundle; the bundle SHOULD be deleted from the network.

If the asserted lifetime for a received bundle is so lengthy that retention of the bundle until its expiration time might degrade operation of the node at which the bundle is received, or if the BPA of that node determines that the bundle must be deleted in order to prevent network performance degradation (e.g., the bundle appears to be part of a denial-of-service attack), then that BPA MAY impose a temporary overriding lifetime of shorter duration; such an overriding lifetime SHALL NOT replace the lifetime asserted in the bundle but SHALL serve as the bundle's effective lifetime while the bundle resides at that node. Procedures for imposing lifetime overrides are beyond the scope of this specification.

For bundles originating at nodes that lack accurate clocks, it is recommended that bundle age be obtained from the Bundle Age extension block (see Section 4.4.2) rather than from the difference between current time and bundle creation time. Bundle lifetime SHALL be represented as a CBOR unsigned integer item.

Fragment offset:

If and only if the bundle processing control flags of this primary block indicate that the bundle is a fragment, fragment offset SHALL be present in the primary block. Fragment offset SHALL be represented as a CBOR unsigned integer indicating the offset from the start of the original ADU at which the bytes comprising the payload of this bundle were located.

Total Application Data Unit Length:

If and only if the bundle processing control flags of this primary block indicate that the bundle is a fragment, total application data unit length SHALL be present in the primary block. Total application data unit length SHALL be represented as a CBOR unsigned integer indicating the total length of the original ADU of which this bundle's payload is a part.

CRC:

A CRC SHALL be present in the primary block unless the bundle includes a BPSec Block Integrity Block [BPSEC] whose target is the primary block, in which case a CRC MAY be present in the primary block. The length and nature of the CRC SHALL be as indicated by the CRC type. The CRC SHALL be computed over the concatenation of all bytes (including CBOR "break" characters) of the primary block including the CRC field itself, which, for this purpose, SHALL be temporarily populated with all bytes set to zero.

Block type code:

An unsigned integer. Bundle block type code 1 indicates that the block is a Bundle Payload Block. Other block type codes are described in Section 9.1. Block type codes 192 through 255 are not reserved and are available for private and/or experimental use. All other block type code values are reserved for future use.

Block number:

An unsigned integer as discussed in Section 4.1. The block number SHALL be represented as a CBOR unsigned integer.

Block processing control flags:

As discussed in Section 4.2.4.

CRC type:

As discussed in Section 4.2.1.

Block-type-specific data:

Represented as a single definite-length CBOR byte string, i.e., a CBOR byte string that is not of indefinite length. For each type of block, the block-type-specific data byte string is the serialization, in a block-type-specific manner, of the data conveyed by that type of block; definitions of blocks are required to define the manner in which block-type-specific data are serialized within the block-type-specific data field. For the Bundle Payload Block in particular (block type 1), the block-type-specific data field, termed the "payload", SHALL be an ADU, or some contiguous extent thereof, represented as a definite-length CBOR byte string.

If and only if the value of the CRC type field of this block is non-zero:

A CRC. If present, the length and nature of the CRC SHALL be as indicated by the CRC type and the CRC SHALL be computed over the concatenation of all bytes of the block (including CBOR "break" characters) including the CRC field itself, which, for this purpose, SHALL be temporarily populated with all bytes set to zero.

• A "bundle reception status report" is a bundle status report with the "Reporting node received bundle" flag set to 1.
• A "bundle forwarding status report" is a bundle status report with the "Reporting node forwarded the bundle" flag set to 1.
• A "bundle delivery status report" is a bundle status report with the "Reporting node delivered the bundle" flag set to 1.
• A "bundle deletion status report" is a bundle status report with the "Reporting node deleted the bundle" flag set to 1.

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.

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.

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 the "request reporting of bundle forwarding" flag in the bundle's status report request field is set to 1 and status reporting is enabled, then a bundle forwarding status report SHOULD be generated, destined for the bundle's report-to endpoint ID. The reason code on this bundle forwarding status report MUST be "no additional information".
• If any applicable Bundle Protocol extensions mandate generation of status reports upon conclusion of convergence-layer data-sending procedures, all such status reports SHOULD be generated with extension-mandated reason codes.
• The bundle's "Forward pending" retention constraint MUST be removed.

Step 1:

The BPA MUST determine whether or not to declare failure in forwarding the bundle. Note: This decision is likely to be influenced by the reason for which forwarding is contraindicated.

Step 2:

If forwarding failure is declared, then the Forwarding Failed procedure defined in Section 5.4.2 MUST be followed.

Step 1:

The BPA MAY forward the bundle back to the node that sent it, as identified by the Previous Node Block, if present. This forwarding, if performed, SHALL be accomplished by performing Step 4 and Step 5 of Section 5.4 where the sole node selected for forwarding SHALL be the node that sent the bundle.

Step 2:

If the bundle's destination endpoint is an endpoint of which the node is a member, then the bundle's "Forward pending" retention constraint MUST be removed. Otherwise, the bundle MUST be deleted: the Bundle Deletion procedure defined in Section 5.10 MUST be followed, citing the reason for which forwarding was determined to be contraindicated.

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.

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.

• The concatenation of the payloads of all fragments produced by fragmentation MUST always be identical to the payload of the fragmented bundle (that is, the bundle that is being fragmented). Note that the payloads of fragments resulting from different fragmentation episodes, in different parts of the network, may be overlapping subsets of the fragmented bundle's payload.
• The primary block of each fragment MUST differ from that of the fragmented bundle, in that the bundle processing control flags of the fragment MUST indicate that the bundle is a fragment and both fragment offset and total application data unit length must be provided. Additionally, the CRC of the primary block of the fragmented bundle, if any, MUST be replaced in each fragment by a new CRC computed for the primary block of that fragment.
• The payload blocks of fragments will differ from that of the fragmented bundle as noted above.
• If the fragmented bundle is not a fragment or is the fragment with offset zero, then all extension blocks of the fragmented bundle MUST be replicated in the fragment whose offset is zero.
• Each of the fragmented bundle's extension blocks whose "Block must be replicated in every fragment" flag is set to 1 MUST be replicated in every fragment.
• Beyond these rules, rules for the replication of extension blocks in the fragments must be defined in the specifications for those extension block types.

• This byte array -- the reassembled ADU -- MUST replace the payload of that fragment whose material extents include the extent at offset zero. Note that this will enable delivery of the reconstituted original bundle as described in Step 1 of Section 5.7.
• The "Reassembly pending" retention constraint MUST be removed from every other fragment with the same source node ID and creation timestamp as this fragment.

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.

• A record type code (an unsigned integer for which valid values are as defined below).
• Record content in type-specific format.

• Reporting node received bundle.
• Reporting node forwarded the bundle.
• Reporting node delivered the bundle.
• Reporting node deleted the bundle.

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.

• sending a bundle to a bundle node that is reachable via the convergence-layer protocol.
• notifying the BPA of the disposition of its data-sending procedures with regard to a bundle, upon concluding those procedures.
• delivering to the BPA a bundle that was sent by a bundle node via the convergence-layer protocol.

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]

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]

[BPSEC]

E Birrane, III, and K McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022,
<https://www.rfc-editor.org/info/rfc9172>.

[CRC16]

ITU-T, "X.25: Interface between Data Terminal Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit", ITU-T Recommendation X.25, October 1996,
<https://www.itu.int/rec/T-REC-X.25-199610-I/>.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4960]

R. Stewart, "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.

[RFC5234]

D. Crocker, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8949]

C. Bormann, and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.

[SABR]

Consultative Committee for Space Data Systems, "Schedule-Aware Bundle Routing", CCSDS Recommended Standard 734.3-B-1, July 2019,
<https://public.ccsds.org/Pubs/734x3b1.pdf>.

[TCPCL]

B Sipos, M Demmer, J Ott, and S Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/info/rfc9174>.

[URI]

T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.

[URIREG]

D. Thaler, T. Hansen, and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015,
<https://www.rfc-editor.org/info/rfc7595>.

[ARCH]

V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007,
<https://www.rfc-editor.org/info/rfc4838>.

[BIBE]

JPL, Calif. Inst. Of Technology, , "Bundle-in-Bundle Encapsulation", Internet-Draft draft-ietf-dtn-bibect-03, February 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bibect-03>.

[RFC3987]

M. Duerst, and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005,
<https://www.rfc-editor.org/info/rfc3987>.

[RFC5050]

K. Scott, and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007,
<https://www.rfc-editor.org/info/rfc5050>.

[RFC6255]

M. Blanchet, "Delay-Tolerant Networking Bundle Protocol IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May 2011,
<https://www.rfc-editor.org/info/rfc6255>.

[RFC6257]

S. Symington, S. Farrell, H. Weiss, and P. Lovell, "Bundle Security Protocol Specification", RFC 6257, DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/info/rfc6257>.

[RFC6258]

S. Symington, "Delay-Tolerant Networking Metadata Extension Block", RFC 6258, DOI 10.17487/RFC6258, May 2011,
<https://www.rfc-editor.org/info/rfc6258>.

[RFC6259]

S. Symington, "Delay-Tolerant Networking Previous-Hop Insertion Block", RFC 6259, DOI 10.17487/RFC6259, May 2011,
<https://www.rfc-editor.org/info/rfc6259>.

[RFC6260]

S. Burleigh, "Compressed Bundle Header Encoding (CBHE)", RFC 6260, DOI 10.17487/RFC6260, May 2011,
<https://www.rfc-editor.org/info/rfc6260>.

[RFC7143]

M. Chadalapaka, J. Satran, K. Meth, and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014,
<https://www.rfc-editor.org/info/rfc7143>.

[RFC8126]

M. Cotton, B. Leiba, and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.

[SIGC]

K Fall, "A Delay-Tolerant Network Architecture for Challenged Internets", DOI 10.1145/863955.863960, August 2003,
<https://dl.acm.org/doi/10.1145/863955.863960>.

• Clarifies the difference between transmission and forwarding.
• Migrates custody transfer to the bundle-in-bundle encapsulation specification [BIBE].
• Introduces the concept of "node ID" as functionally distinct from endpoint ID, while having the same syntax.
• Restructures primary block, making it immutable. Adds optional CRC.
• Adds optional CRCs to non-primary blocks.
• Adds block ID number to canonical block format (to support BPSec).
• Adds definition of Bundle Age extension block.
• Adds definition of Previous Node extension block.
• Adds definition of Hop Count extension block.
• Removes Quality of Service markings.
• Changes from Self-Delimiting Numeric Values (SDNVs) to CBOR encoding.
• Adds lifetime overrides.
• Clarifies that time values are denominated in milliseconds, not seconds.

Scott Burleigh

Kevin Fall

Edward J. Birrane, III