| RFC 9171 | Bundle Protocol Version 7 | January 2022 |
| Burleigh, et al. | Standards Track | [Page] |
This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9171.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Since the publication of the Bundle Protocol specification (Experimental RFC 5050 [RFC5050]) in 2007, the Delay-Tolerant Networking (DTN) Bundle Protocol (BP) has been implemented in multiple programming languages and deployed to a wide variety of computing platforms. This implementation and deployment experience has identified opportunities for making the protocol simpler, more capable, and easier to use. The present document, standardizing the Bundle Protocol, is adapted from RFC 5050 in that context, reflecting lessons learned. Significant changes from the Bundle Protocol specification defined in RFC 5050 are listed in Appendix A.¶
This document describes BP version 7 (BPv7).¶
Delay-Tolerant Networking is a network architecture providing communications in and/or through highly stressed environments. Stressed networking environments include those with intermittent connectivity, large and/or variable delays, and high bit error rates. To provide its services, BP may be viewed as sitting at the application layer of some number of constituent networks, forming a store-carry-forward overlay network. Key capabilities of BP include:¶
For descriptions of these capabilities and the rationale for the DTN architecture, see [ARCH] and [SIGC].¶
BP's location within the standard protocol stack is as shown in Figure 1. BP uses underlying "integrated" transport and/or network protocols for communications within a given constituent network. The layer at which those underlying protocols are located is here termed the "convergence layer", and the interface between the Bundle Protocol and a specific underlying protocol is termed a "convergence-layer adapter".¶
Figure 1 shows three distinct transport and network protocols (denoted T1/N1, T2/N2, and T3/N3).¶
+-----------+ +-----------+ | 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 ---->| | | | |
This document describes the format of the protocol data units (PDUs) (called "bundles") passed between entities participating in BP communications.¶
The entities are referred to as "bundle nodes". This document does not address:¶
Note that implementations of the specification presented in this document will not be interoperable with implementations of RFC 5050.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
+-----------------------------------------------------------+
|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
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:¶
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.¶
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.¶
CRC type is an unsigned integer type code for which the following values (and no others) are valid:¶
CRC type SHALL be represented as a CBOR unsigned integer.¶
For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143].¶
Note that more robust protection of BP data integrity, as needed, may be provided by means of Block Integrity Blocks (BIBs) as defined in the Bundle Protocol Security specification [BPSEC].¶
The CRC SHALL be omitted from a block if and only if the block's CRC type code is zero.¶
When not omitted, the CRC SHALL be represented as a CBOR byte string of two bytes (that is, CBOR additional information 2, if CRC type is 1) or of four bytes (that is, CBOR additional information 4, if CRC type is 2); in each case, the sequence of bytes SHALL constitute an unsigned integer value (of 16 or 32 bits, respectively) in network byte order.¶
Bundle processing control flags assert properties of the bundle as a whole rather than of any particular block of the bundle. They are conveyed in the primary block of the bundle.¶
The following properties are asserted by the bundle processing control flags:¶
Flags requesting types of status reports (all Boolean):¶
If the bundle processing control flags indicate that the bundle's ADU is an administrative record, then all status report request flag values MUST be zero.¶
If the bundle's source node is omitted (i.e., the source node ID is the ID of the null endpoint, which has no members as discussed below; this option enables anonymous bundle transmission), then the bundle is not uniquely identifiable and all Bundle Protocol features that rely on bundle identity must therefore be disabled: the "Bundle must not be fragmented" flag value MUST be 1, and all status report request flag values MUST be zero.¶
Bundle processing control flags that are unrecognized MUST be ignored, as future definitions of additional flags might not be integrated simultaneously into the Bundle Protocol implementations operating at all nodes.¶
The bundle processing control flags SHALL be represented as a CBOR unsigned integer item, the value of which SHALL be processed as a bit field indicating the control flag values as follows (note that bit numbering in this instance is reversed from the usual practice, beginning with the low-order bit instead of the high-order bit, in recognition of the potential definition of additional control flag values in the future):¶
The block processing control flags assert properties of canonical bundle blocks. They are conveyed in the header of the block to which they pertain.¶
Block processing control flags that are unrecognized MUST be ignored, as future definitions of additional flags might not be integrated simultaneously into the Bundle Protocol implementations operating at all nodes.¶
The block processing control flags SHALL be represented as a CBOR unsigned integer item, the value of which SHALL be processed as a bit field indicating the control flag values as follows (note that bit numbering in this instance is reversed from the usual practice, beginning with the low-order bit instead of the high-order bit, for agreement with the bit numbering of the bundle processing control flags):¶
For each bundle whose bundle processing control flags indicate that the bundle's ADU is an administrative record, or whose source node ID is the null endpoint ID as defined below, the value of the "Transmit status report if block can't be processed" flag in every canonical block of the bundle MUST be zero.¶
The destinations of bundles are bundle endpoints, identified by text strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID (EID) is a Uniform Resource Identifier [URI]. As such, each endpoint ID can be characterized as having this general structure:¶
< scheme name > : < scheme-specific part, or "SSP" >¶
The scheme identified by the < scheme name > in an endpoint ID is a set of syntactic and semantic rules that fully explain how to parse and interpret the scheme-specific part (SSP). Each scheme that may be used to form a BP endpoint ID must be added to the "Bundle Protocol URI Scheme Types" registry, maintained by IANA as described in Section 9.6; association of a unique URI scheme code number with each scheme name in this registry helps to enable compact representation of endpoint IDs in bundle blocks. Note that the set of allowable schemes is effectively unlimited. Any scheme conforming to [URIREG] may be added to the registry of URI scheme code numbers and thereupon used in a Bundle Protocol endpoint ID.¶
Each entry in the registry of URI scheme code numbers MUST contain a reference to a scheme code number definition document, which defines the manner in which the scheme-specific part of any URI formed in that scheme is parsed and interpreted and MUST be CBOR encoded for transmission as a BP endpoint ID. The scheme code number definition document may also contain information as to (a) which convergence-layer protocol(s) may be used to forward a bundle to a BP destination endpoint identified by such an ID and (b) how the ID of the convergence-layer protocol endpoint to use for that purpose can be inferred from that destination endpoint ID.¶
Note that, although endpoint IDs are URIs, implementations of the BP service interface may support expression of endpoint IDs in some internationalized manner (e.g., Internationalized Resource Identifiers (IRIs); see [RFC3987]).¶
Each BP endpoint ID (EID) SHALL be represented as a CBOR array comprising two items.¶
The first item of the array SHALL be the code number identifying the endpoint ID's URI scheme, as defined in the registry of URI scheme code numbers for the Bundle Protocol. Each URI scheme code number SHALL be represented as a CBOR unsigned integer.¶
The second item of the array SHALL be the applicable CBOR encoding of the scheme-specific part of the EID, defined as noted in the references(s) for the URI scheme code number registry entry for the EID's URI scheme.¶
The "dtn" scheme supports the identification of BP endpoints by arbitrarily expressive character strings. It is specified as follows:¶
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
¶
The endpoint ID "dtn:none" identifies the "null endpoint", the endpoint that by definition never has any members.¶
All BP endpoints identified by all other dtn-scheme endpoint IDs for which the first character of demux is a character other than '~' (tilde) are singleton endpoints. All BP endpoints identified by dtn-scheme endpoint IDs for which the first character is '~' (tilde) are not singleton endpoints.¶
A dtn-scheme endpoint ID for which the demux is of length zero MAY identify the administrative endpoint for the node identified by node-name, and as such may serve as a node ID. No dtn-scheme endpoint ID for which the demux is of non-zero length may do so.¶
Note that these syntactic rules impose constraints on dtn-scheme endpoint IDs that were not imposed by the original specification of the dtn scheme as provided in [RFC5050]. It is believed that the dtn-scheme endpoint IDs employed by BP applications conforming to [RFC5050] are in most cases unlikely to be in violation of these rules, but the developers of such applications are advised of the potential for compromised interoperation.¶
The "ipn" scheme supports the identification of BP endpoints by pairs of unsigned integers, for compact representation in bundle blocks. It is specified as follows:¶
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¶
All BP endpoints identified by ipn-scheme endpoint IDs are singleton endpoints.¶
An ipn-scheme endpoint ID for which service-nbr is zero MAY identify the administrative endpoint for the node identified by node-nbr, and as such may serve as a node ID. No ipn-scheme endpoint ID for which service-nbr is non-zero may do so.¶
For many purposes of the Bundle Protocol, it is important to identify the node that is operative in some context.¶
As discussed in Section 3.1, nodes are distinct from endpoints; specifically, an endpoint is a set of zero or more nodes. But rather than define a separate namespace for node identifiers, we instead use endpoint identifiers to identify nodes as discussed in Section 3.2. Formally:¶
A DTN time is an unsigned integer indicating the number of milliseconds that have elapsed since the DTN Epoch, 2000-01-01 00:00:00 +0000 (UTC). DTN time is not affected by leap seconds.¶
Each DTN time SHALL be represented as a CBOR unsigned integer item. Implementers need to be aware that DTN time values conveyed in CBOR encoding in bundles will nearly always exceed (232 - 1); the manner in which a DTN time value is represented in memory is an implementation matter. The DTN time value zero indicates that the time is unknown.¶
Each bundle's creation timestamp SHALL be represented as a CBOR array comprising two items.¶
The first item of the array, termed "bundle creation time", SHALL be the DTN time at which the transmission request was received that resulted in the creation of the bundle, represented as a CBOR unsigned integer.¶
The second item of the array, termed the creation timestamp's "sequence number", SHALL be the latest value (as of the time at which the transmission request was received) of a monotonically increasing positive integer counter managed by the source node's BPA, represented as a CBOR unsigned integer. The sequence counter MAY be reset to zero whenever the current time advances by one millisecond.¶
For nodes that lack accurate clocks, it is recommended that bundle creation time be set to zero and that the counter used as the source of the bundle sequence count never be reset to zero.¶
Note that, in general, the creation of two distinct bundles with the same source node ID and bundle creation timestamp may result in unexpected network behavior and/or suboptimal performance. The combination of source node ID and bundle creation timestamp serves to identify a single transmission request, enabling it to be acknowledged by the receiving application (provided the source node ID is not the null endpoint ID).¶
Block-type-specific data in each block (other than the primary block) SHALL be the applicable CBOR encoding of the content of the block. Details of this representation are included in the specification defining the block type.¶
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.¶
The primary bundle block contains the basic information needed to forward bundles to their destinations.¶
Each primary block SHALL be represented as a CBOR array; the number of elements in the array SHALL be 8 (if the bundle is not a fragment and the block has no CRC), 9 (if the block has a CRC and the bundle is not a fragment), 10 (if the bundle is a fragment and the block has no CRC), or 11 (if the bundle is a fragment and the block has a CRC).¶
The primary block of each bundle SHALL be immutable. The CBOR- encoded values of all fields in the primary block MUST remain unchanged from the time the block is created to the time it is delivered.¶
The fields of the primary bundle block SHALL be as follows, listed in the order in which they MUST appear:¶
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.¶
Every block other than the primary block (all such blocks are termed "canonical" blocks) SHALL be represented as a CBOR array; the number of elements in the array SHALL be 5 (if CRC type is zero) or 6 (otherwise).¶
The fields of every canonical block SHALL be as follows, listed in the order in which they MUST appear:¶
"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.¶
The Previous Node Block, block type 6, identifies the node that forwarded this bundle to the local node (i.e., to the node at which the bundle currently resides); its block-type-specific data is the node ID of that forwarder node. That node ID SHALL conform to Section 4.2.5.2. If the local node is the source of the bundle, then the bundle MUST NOT contain any Previous Node Block. Otherwise, the bundle SHOULD contain one (1) occurrence of this type of block and MUST NOT contain more than one.¶
The Bundle Age Block, block type 7, contains the number of milliseconds that have elapsed between the time the bundle was created and the time at which it was most recently forwarded. It is intended for use by nodes lacking access to an accurate clock, to aid in determining the time at which a bundle's lifetime expires. The block-type-specific data of this block is an unsigned integer containing the age of the bundle in milliseconds, which SHALL be represented as a CBOR unsigned integer item. (The age of the bundle is the sum of all known intervals of the bundle's residence at forwarding nodes, up to the time at which the bundle was most recently forwarded, plus the summation of signal propagation time over all episodes of transmission between forwarding nodes. Determination of these values is an implementation matter.) If the bundle's creation time is zero, then the bundle MUST contain exactly one (1) occurrence of this type of block; otherwise, the bundle MAY contain at most one (1) occurrence of this type of block. A bundle MUST NOT contain multiple occurrences of the Bundle Age Block, as this could result in processing anomalies.¶
The Hop Count Block, block type 10, contains two unsigned integers: hop limit and hop count. A "hop" is here defined as an occasion on which a bundle was forwarded from one node to another node. The hop limit MUST be in the range 1 through 255. The hop limit value SHOULD NOT be changed at any time after creation of the Hop Count Block; the hop count value SHOULD initially be zero and SHOULD be increased by 1 on each hop.¶
The Hop Count Block is mainly intended as a safety mechanism, a means of identifying bundles for removal from the network that can never be delivered due to a persistent forwarding error. The hop count is particularly valuable as a defense against routing anomalies that might cause a bundle to be forwarded in a cyclical "ping-pong" fashion between two nodes. When a bundle's hop count exceeds its hop limit, the bundle SHOULD be deleted for the reason "Hop limit exceeded", following the Bundle Deletion procedure defined in Section 5.10.¶
Procedures for determining the appropriate hop limit for a bundle are beyond the scope of this specification.¶
The block-type-specific data in a Hop Count Block SHALL be represented as a CBOR array comprising two items. The first item of this array SHALL be the bundle's hop limit, represented as a CBOR unsigned integer. The second item of this array SHALL be the bundle's hop count, represented as a CBOR unsigned integer. A bundle MAY contain one occurrence of this type of block but MUST NOT contain more than one.¶
The bundle-processing procedures mandated in this section and in Section 6 govern the operation of the BPA and the application agent administrative element of each bundle node. They are neither exhaustive nor exclusive. Supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may augment, override, or supersede the mandates of this document.¶
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:¶
The steps in processing a bundle transmission request are as follows:¶
(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:¶
The steps in forwarding a bundle are as follows:¶
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:¶
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 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:¶
The steps in responding to contraindication of forwarding are as follows:¶
Otherwise, when -- at some future time -- the forwarding of this bundle ceases to be contraindicated, processing proceeds from Step 4 of Section 5.4.¶
The steps in responding to a declaration of forwarding failure are as follows:¶
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.¶
The steps in processing a bundle that has been received from another node are as follows:¶
For each block in the bundle that is an extension block that the BPA cannot process:¶
The steps in processing a bundle that is destined for an endpoint of which this node is a member are as follows:¶
Delivery depends on the state of the registration whose endpoint ID matches that of the destination of the bundle:¶
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:¶
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:¶
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.¶
The steps in deleting a bundle are as follows:¶
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.¶
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.¶
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.¶
The transmission of "bundle status reports" under specified conditions is an option that can be invoked when transmission of a bundle is requested. These reports are intended to provide information about how bundles are progressing through the system, including notices of receipt, forwarding, final delivery, and deletion. They are transmitted to the report-to endpoints of bundles.¶
Each bundle status report SHALL be represented as a CBOR array. The number of elements in the array SHALL be either 6 (if the subject bundle is a fragment) or 4 (otherwise).¶
The first element of the bundle status report SHALL be bundle status information represented as a CBOR array of at least four elements. The first four elements of the bundle status information shall provide information on the following four status assertions, in this order:¶
Each element of the bundle status information SHALL be a bundle status item encoded as a CBOR array.¶
The number of elements in each bundle status item SHALL be either 2 (if the value of the first element of the bundle status item is 1 AND the "Report status time" flag was set to 1 in the bundle processing control flags of the bundle whose status is being reported) or 1 (otherwise).¶
The first element of each bundle status item SHALL be a status indicator, a Boolean value indicating whether or not the corresponding bundle status is asserted, encoded as a CBOR Boolean value. If present, the second element of each bundle status item SHALL indicate the time (as reported by the local system clock; this is an implementation matter) at which the indicated status was asserted for this bundle, represented as a DTN time as described in Section 4.2.6.¶
The second element of the bundle status report SHALL be the bundle status report reason code explaining the value of the status indicator, represented as a CBOR unsigned integer. Valid status report reason codes are registered in the IANA "Bundle Status Report Reason Codes" subregistry in the "Bundle Protocol" registry (see Section 9.5). The initial contents of that registry are listed in Table 1, but the list of status report reason codes provided here is neither exhaustive nor exclusive; supplementary DTN protocol specifications (including, but not restricted to, Bundle Protocol Security [BPSEC]) may define additional reason codes.¶
| Value | Meaning |
|---|---|
| 0 | No additional information. |
| 1 | Lifetime expired. |
| 2 | Forwarded over unidirectional link. |
| 3 | Transmission canceled. |
| 4 | Depleted storage. |
| 5 | Destination endpoint ID unavailable. |
| 6 | No known route to destination from here. |
| 7 | No timely contact with next node on route. |
| 8 | Block unintelligible. |
| 9 | Hop limit exceeded. |
| 10 | Traffic pared (e.g., status reports). |
| 11 | Block unsupported. |
| 17-254 | Unassigned |
| 255 | Reserved |
The third element of the bundle status report SHALL be the source node ID identifying the source of the bundle whose status is being reported, represented as described in Section 4.2.5.1.1.¶
The fourth element of the bundle status report SHALL be the creation timestamp of the bundle whose status is being reported, represented as described in Section 4.2.7.¶
The fifth element of the bundle status report SHALL be present if and only if the bundle whose status is being reported contained a fragment offset. If present, it SHALL be the subject bundle's fragment offset represented as a CBOR unsigned integer item.¶
The sixth element of the bundle status report SHALL be present if and only if the bundle whose status is being reported contained a fragment offset. If present, it SHALL be the length of the subject bundle's payload represented as a CBOR unsigned integer item.¶
Note that the forwarding parameters (such as lifetime, applicable security measures, etc.) of the bundle whose status is being reported MAY be reflected in the parameters governing the forwarding of the bundle that conveys a status report, but this is an implementation matter. Bundle Protocol deployment experience to date has not been sufficient to suggest any clear guidance on this topic.¶
Whenever the application agent's administrative element is directed by the BPA to generate an administrative record, the following procedure must be followed:¶
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.¶
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.¶
The Bundle Protocol security architecture and the available security services are specified in an accompanying document, the Bundle Protocol Security (BPSec) specification [BPSEC]. Whenever Bundle Protocol security services (as opposed to the security services provided by overlying application protocols or underlying convergence-layer protocols) are required, those services SHALL be provided by BPSec rather than by some other mechanism with the same or similar scope.¶
A Bundle Protocol Agent (BPA) that sources, cryptographically verifies, and/or accepts a bundle MUST implement support for BPSec. Use of BPSec for any single bundle is optional.¶
The BPSec extensions to the Bundle Protocol enable each block of a bundle (other than a BPSec extension block) to be individually authenticated by a signature block (Block Integrity Block, or BIB) and also enable each block of a bundle other than the primary block (and the BPSec extension blocks themselves) to be individually encrypted by a Block Confidentiality Block (BCB).¶
Because the security mechanisms are extension blocks that are themselves inserted into the bundle, the protections they afford apply while the bundle is at rest, awaiting transmission at the next forwarding opportunity, as well as in transit.¶
Additionally, convergence-layer protocols that ensure authenticity of communication between adjacent nodes in a BP network topology SHOULD be used where available, to minimize the ability of unauthenticated nodes to introduce inauthentic traffic into the network. Convergence-layer protocols that ensure confidentiality of communication between adjacent nodes in a BP network topology SHOULD also be used where available, to minimize exposure of the bundle's primary block and other cleartext blocks, thereby offering some defense against traffic analysis.¶
In order to provide authenticity and/or confidentiality of communication between BP nodes, the convergence-layer protocol requires as input the name or names of the expected communication peer(s). These must be supplied by the CLA. Details of the means by which the CLA determines which CL endpoint name(s) must be provided to the CL protocol are out of scope for this specification. Note, though, that when the CL endpoint names are a function of BP endpoint IDs, the correctness and authenticity of that mapping will be vital to the overall security properties that the CL provides to the system.¶
Note that, while the primary block must remain in the clear for routing purposes, the Bundle Protocol could be protected against traffic analysis to some extent by using bundle-in-bundle encapsulation [BIBE] to tunnel bundles to a safe forward distribution point: the encapsulated bundle could form the payload of an encapsulating bundle, and that payload block could be encrypted by a BCB.¶
Note that the generation of bundle status reports is disabled by default because malicious initiation of bundle status reporting could result in the transmission of extremely large numbers of bundles, effecting a denial-of-service attack. Imposing bundle lifetime overrides would constitute one defense against such an attack.¶
Note also that the reception of large numbers of fragmentary bundles with very long lifetimes could constitute a denial-of-service attack, occupying storage while pending reassembly that will never occur. Imposing bundle lifetime overrides would, again, constitute one defense against such an attack.¶
This protocol makes use of absolute timestamps for several purposes. Provisions are included for nodes without accurate clocks to retain most of the protocol functionality, but nodes that are unaware that their clock is inaccurate may exhibit unexpected behavior.¶
The Bundle Protocol includes fields requiring registries managed by IANA.¶
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.¶
| Bundle Protocol Version | Value | Description | Reference |
|---|---|---|---|
| none | 0 | Reserved | [RFC6255] |
| 6,7 | 1 | Bundle Payload Block | [RFC5050] [RFC9171] |
| 6 | 2 | Bundle Authentication Block | [RFC6257] |
| 6 | 3 | Payload Integrity Block | [RFC6257] |
| 6 | 4 | Payload Confidentiality Block | [RFC6257] |
| 6 | 5 | Previous-Hop Insertion Block | [RFC6259] |
| 7 | 6 | Previous node (proximate sender) | [RFC9171] |
| 7 | 7 | Bundle age (in milliseconds) | [RFC9171] |
| 6 | 8 | Metadata Extension Block | [RFC6258] |
| 6 | 9 | Extension Security Block | [RFC6257] |
| 7 | 10 | Hop count (#prior xmit attempts) | [RFC9171] |
| 7 | 11-191 | Unassigned | |
| 6,7 | 192-255 | Reserved for Private and/or Experimental Use | [RFC5050] [RFC9171] |
IANA has added the following value to the "Primary Bundle Protocol Version" subregistry in the "Bundle Protocol" registry.¶
| Value | Description | Reference |
|---|---|---|
| 7 | Assigned | [RFC9171] |
Values 8-255 (rather than 7-255) are now Unassigned.¶
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.¶
| Bundle Protocol Version | Bit Position (right to left) | Description | Reference |
|---|---|---|---|
| 6,7 | 0 | Bundle is a fragment | [RFC5050] [RFC9171] |
| 6,7 | 1 | ADU is an administrative record | [RFC5050] [RFC9171] |
| 6,7 | 2 | Bundle must not be fragmented | [RFC5050] [RFC9171] |
| 6 | 3 | Custody transfer is requested | [RFC5050] |
| 6 | 4 | Destination endpoint is a singleton | [RFC5050] |
| 6,7 | 5 | Acknowledgement by application is requested | [RFC5050] [RFC9171] |
| 7 | 6 | Status time requested in reports | [RFC9171] |
| 6 | 7-8 | Class of service: priority | [RFC5050] |
| 6 | 9-13 | Class of service: reserved | [RFC5050] |
| 6,7 | 14 | Request reporting of bundle reception | [RFC5050] [RFC9171] |
| 6 | 15 | Request reporting of custody acceptance | [RFC5050] |
| 6,7 | 16 | Request reporting of bundle forwarding | [RFC5050] [RFC9171] |
| 6,7 | 17 | Request reporting of bundle delivery | [RFC5050] [RFC9171] |
| 6,7 | 18 | Request reporting of bundle deletion | [RFC5050] [RFC9171] |
| 6,7 | 19 | Reserved | [RFC5050] [RFC9171] |
| 6,7 | 20 | Reserved | [RFC5050] [RFC9171] |
| 21-63 | Unassigned |
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.¶
| Bundle Protocol Version |
Bit Position (right to left)¶ |
Description | Reference |
|---|---|---|---|
| 6,7 | 0 | Block must be replicated in every fragment | [RFC5050] [RFC9171] |
| 6,7 | 1 | Transmit status report if block can't be processed | [RFC5050] [RFC9171] |
| 6,7 | 2 | Delete bundle if block can't be processed | [RFC5050] [RFC9171] |
| 6 | 3 | Last block | [RFC5050] |
| 6,7 | 4 | Discard block if it can't be processed | [RFC5050] [RFC9171] |
| 6 | 5 | Block was forwarded without being processed | [RFC5050] |
| 6 | 6 | Block contains an EID-reference field | [RFC5050] |
| 7-63 | Unassigned |
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.¶
| Bundle Protocol Version | Value | Description | Reference |
|---|---|---|---|
| 6,7 | 0 | No additional information | [RFC5050] [RFC9171] |
| 6,7 | 1 | Lifetime expired | [RFC5050] [RFC9171] |
| 6,7 | 2 | Forwarded over unidirectional link | [RFC5050] [RFC9171] |
| 6,7 | 3 | Transmission canceled | [RFC5050] [RFC9171] |
| 6,7 | 4 | Depleted storage | [RFC5050] [RFC9171] |
| 6,7 | 5 | Destination endpoint ID unavailable | [RFC5050] [RFC9171] |
| 6,7 | 6 | No known route to destination from here | [RFC5050] [RFC9171] |
| 6,7 | 7 | No timely contact with next node on route | [RFC5050] [RFC9171] |
| 6,7 | 8 | Block unintelligible | [RFC5050] [RFC9171] |
| 7 | 9 | Hop limit exceeded | [RFC9171] |
| 7 | 10 | Traffic pared | [RFC9171] |
| 7 | 11 | Block unsupported | [RFC9171] |
| 17-254 | Unassigned | ||
| 6,7 | 255 | Reserved | [RFC6255] [RFC9171] |
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).¶
| Value | Description | BP Utilization Reference | URI Definition Reference |
|---|---|---|---|
| 0 | Reserved | n/a | |
| 1 | dtn | [RFC9171] | [RFC9171] |
| 2 | ipn | [RFC9171] | [RFC6260] [RFC9171] |
| 3-254 | Unassigned | n/a | |
| 255-65535 | Reserved | n/a | |
| >65535 | Reserved for Private Use | n/a |
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:¶
Scott Burleigh <[email protected]>¶
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.¶
Scott Burleigh <[email protected]>¶
This document makes the following significant changes from RFC 5050:¶
For informational purposes, Carsten Bormann and Brian Sipos have kindly provided an expression of the Bundle Protocol specification in the Concise Data Definition Language (CDDL). That CDDL expression is presented below. Note that wherever the CDDL expression is in disagreement with the textual representation of the BP specification presented in the earlier sections of this document, the textual representation rules.¶
bpv7_start = bundle / #6.55799(bundle)
; Times before 2000 are invalid
dtn-time = uint
; CRC enumerated type
crc-type = &(
crc-none: 0,
crc-16bit: 1,
crc-32bit: 2
)
; Either 16-bit or 32-bit
crc-value = (bstr .size 2) / (bstr .size 4)
creation-timestamp = [
dtn-time, ; absolute time of creation
sequence: uint ; sequence within the time
]
eid = $eid .within eid-structure
eid-structure = [
uri-code: uint,
SSP: any
]
$eid /= [
uri-code: 1,
SSP: (tstr / 0)
]
$eid /= [
uri-code: 2,
SSP: [
nodenum: uint,
servicenum: uint
]
]
; The root bundle array
bundle = [primary-block, *extension-block, payload-block]
primary-block = [
version: 7,
bundle-control-flags,
crc-type,
destination: eid,
source-node: eid,
report-to: eid,
creation-timestamp,
lifetime: uint,
? (
fragment-offset: uint,
total-application-data-length: uint
),
? crc-value,
]
bundle-control-flags = uint .bits bundleflagbits
bundleflagbits = &(
reserved: 20,
reserved: 19,
bundle-deletion-status-reports-are-requested: 18,
bundle-delivery-status-reports-are-requested: 17,
bundle-forwarding-status-reports-are-requested: 16,
reserved: 15,
bundle-reception-status-reports-are-requested: 14,
reserved: 13,
reserved: 12,
reserved: 11,
reserved: 10,
reserved: 9,
reserved: 8,
reserved: 7,
status-time-is-requested-in-all-status-reports: 6,
user-application-acknowledgement-is-requested: 5,
reserved: 4,
reserved: 3,
bundle-must-not-be-fragmented: 2,
payload-is-an-administrative-record: 1,
bundle-is-a-fragment: 0
)
; Abstract shared structure of all non-primary blocks
canonical-block-structure = [
block-type-code: uint,
block-number: uint,
block-control-flags,
crc-type,
; Each block type defines the content within the byte string
block-type-specific-data,
? crc-value
]
block-control-flags = uint .bits blockflagbits
blockflagbits = &(
reserved: 7,
reserved: 6,
reserved: 5,
block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4,
reserved: 3,
bundle-must-be-deleted-if-block-cannot-be-processed: 2,
status-report-must-be-transmitted-if-block-cannot-be-processed:
1,
block-must-be-replicated-in-every-fragment: 0
)
block-type-specific-data = bstr / #6.24(bstr)
; Actual CBOR data embedded in a byte string, with optional tag to
indicate so.
; Additional plain bstr allows ciphertext data.
embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) /
bstr
; Extension block type, which does not specialize other than the
code/number
extension-block =
$extension-block .within canonical-block-structure
; Generic shared structure of all non-primary blocks
extension-block-use<CodeValue, BlockData> = [
block-type-code: CodeValue,
block-number: (uint .gt 1),
block-control-flags,
crc-type,
BlockData,
? crc-value
]
; Payload block type
payload-block = payload-block-structure .within canonical-block-
structure
payload-block-structure = [
block-type-code: 1,
block-number: 1,
block-control-flags,
crc-type,
$payload-block-data,
? crc-value
]
; Arbitrary payload data, including non-CBOR byte string
$payload-block-data /= block-type-specific-data
; Administrative record as a payload data specialization
$payload-block-data /= embedded-cbor<admin-record>
admin-record = $admin-record .within admin-record-structure
admin-record-structure = [
record-type-code: uint,
record-content: any
]
; Only one defined record type
$admin-record /= [1, status-record-content]
status-record-content = [
bundle-status-information,
status-report-reason-code: uint,
source-node-eid: eid,
subject-creation-timestamp: creation-timestamp,
? (
subject-payload-offset: uint,
subject-payload-length: uint
)
]
bundle-status-information = [
reporting-node-received-bundle: status-info-content,
reporting-node-forwarded-bundle: status-info-content,
reporting-node-delivered-bundle: status-info-content,
reporting-node-deleted-bundle: status-info-content
]
status-info-content = [
status-indicator: bool,
? timestamp: dtn-time
]
; Previous Node extension block
$extension-block /=
extension-block-use<6, embedded-cbor<ext-data-previous-node>>
ext-data-previous-node = eid
; Bundle Age extension block
$extension-block /=
extension-block-use<7, embedded-cbor<ext-data-bundle-age>>
ext-data-bundle-age = uint
; Hop Count extension block
$extension-block /=
extension-block-use<10, embedded-cbor<ext-data-hop-count>>
ext-data-hop-count = [
hop-limit: uint,
hop-count: uint
]
¶
This work is freely adapted from RFC 5050, which was an effort of the Delay-Tolerant Networking Research Group. The following DTNRG participants contributed significant technical material and/or inputs to that document: Dr. Vinton Cerf of Google; Scott Burleigh, Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory; Michael Demmer of the University of California at Berkeley; Robert Durst, Keith Scott, and Susan Symington of The MITRE Corporation; Kevin Fall of Carnegie Mellon University; Stephen Farrell of Trinity College Dublin; Howard Weiss and Peter Lovell of SPARTA, Inc.; and Manikantan Ramadas of Ohio University.¶
Scott Burleigh would like to thank the Jet Propulsion Laboratory, California Institute of Technology, for its generous and sustained support of this work.¶