diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc9171.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc9171.txt')
| -rw-r--r-- | doc/rfc/rfc9171.txt | 2990 |
1 files changed, 2990 insertions, 0 deletions
diff --git a/doc/rfc/rfc9171.txt b/doc/rfc/rfc9171.txt new file mode 100644 index 0000000..62ecea8 --- /dev/null +++ b/doc/rfc/rfc9171.txt @@ -0,0 +1,2990 @@ + + + + +Internet Engineering Task Force (IETF) S. Burleigh +Request for Comments: 9171 IPNGROUP +Category: Standards Track K. Fall +ISSN: 2070-1721 Roland Computing Services + E. Birrane, III + APL, Johns Hopkins University + January 2022 + + + Bundle Protocol Version 7 + +Abstract + + 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. + +Status of This Memo + + 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 Notice + + 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. + +Table of Contents + + 1. Introduction + 2. Conventions Used in This Document + 3. Service Description + 3.1. Definitions + 3.2. Discussion of BP Concepts + 3.3. Services Offered by Bundle Protocol Agents + 4. Bundle Format + 4.1. Bundle Structure + 4.2. BP Fundamental Data Structures + 4.2.1. CRC Type + 4.2.2. CRC + 4.2.3. Bundle Processing Control Flags + 4.2.4. Block Processing Control Flags + 4.2.5. Identifiers + 4.2.5.1. Endpoint ID + 4.2.5.1.1. The dtn URI Scheme + 4.2.5.1.2. The ipn URI Scheme + 4.2.5.2. Node ID + 4.2.6. DTN Time + 4.2.7. Creation Timestamp + 4.2.8. Block-Type-Specific Data + 4.3. Block Structures + 4.3.1. Primary Bundle Block + 4.3.2. Canonical Bundle Block Format + 4.4. Extension Blocks + 4.4.1. Previous Node + 4.4.2. Bundle Age + 4.4.3. Hop Count + 5. Bundle Processing + 5.1. Generation of Administrative Records + 5.2. Bundle Transmission + 5.3. Bundle Dispatching + 5.4. Bundle Forwarding + 5.4.1. Forwarding Contraindicated + 5.4.2. Forwarding Failed + 5.5. Bundle Expiration + 5.6. Bundle Reception + 5.7. Local Bundle Delivery + 5.8. Bundle Fragmentation + 5.9. Application Data Unit Reassembly + 5.10. Bundle Deletion + 5.11. Discarding a Bundle + 5.12. Canceling a Transmission + 6. Administrative Record Processing + 6.1. Administrative Records + 6.1.1. Bundle Status Reports + 6.2. Generation of Administrative Records + 7. Services Required of the Convergence Layer + 7.1. The Convergence Layer + 7.2. Summary of Convergence-Layer Services + 8. Security Considerations + 9. IANA Considerations + 9.1. Bundle Block Types + 9.2. Primary Bundle Protocol Version + 9.3. Bundle Processing Control Flags + 9.4. Block Processing Control Flags + 9.5. Bundle Status Report Reason Codes + 9.6. Bundle Protocol URI Scheme Types + 9.7. dtn URI Scheme + 9.8. ipn URI Scheme + 10. References + 10.1. Normative References + 10.2. Informative References + Appendix A. Significant Changes from RFC 5050 + Appendix B. CDDL Expression + Acknowledgments + Authors' Addresses + +1. Introduction + + 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: + + * 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. + + 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 ---->| + | | | | + + Figure 1: The Bundle Protocol in the Protocol Stack Model + + 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: + + * 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. + + Note that implementations of the specification presented in this + document will not be interoperable with implementations of RFC 5050. + +2. Conventions Used in This Document + + 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. + +3. Service Description + +3.1. Definitions + + Bundle: A bundle is a PDU of BP, so named because negotiation of the + parameters of a data exchange may be impractical in a delay- + tolerant network: it is often better practice to "bundle" with a + unit of application data all metadata that might be needed in + order to make the data immediately usable when delivered to the + application. Each bundle comprises a sequence of two or more + "blocks" of protocol data, which serve various purposes. + + Block: A Bundle Protocol block is one of the protocol data + structures that together constitute a well-formed bundle. + + Application Data Unit: An application data unit (ADU) is the unit of + data whose conveyance to the bundle's destination is the purpose + for the transmission of some bundle that is not a fragment (as + defined below). + + Bundle payload: A bundle payload (or simply "payload") is the + content of the bundle's payload block. The terms "bundle + content", "bundle payload", and "payload" are used interchangeably + in this document. For a bundle that is not a fragment (as defined + below), the payload is an ADU. + + Partial payload: A partial payload is a payload that comprises + either the first N bytes or the last N bytes of some other payload + of length M, such that 0 < N < M. Note that every partial payload + is a payload and therefore can be further subdivided into partial + payloads. + + Fragment: A fragment, a.k.a. "fragmentary bundle", is a bundle whose + payload block contains a partial payload. + + Bundle node: A bundle node (or, in the context of this document, + simply a "node") is any entity that can send and/or receive + bundles. Each bundle node has three conceptual components, + defined below, as shown in Figure 2: a "Bundle Protocol Agent", a + set of zero or more "convergence-layer adapters", and an + "application agent". ("CL1 PDUs" are the PDUs of the convergence- + layer protocol used in network 1.) + + +-----------------------------------------------------------+ + |Node | + | | + | +-------------------------------------------------------+ | + | |Application Agent | | + | | | | + | | +--------------------------+ +----------------------+ | | + | | |Administrative element | |Application-specific | | | + | | | | |element | | | + | | | | | | | | + | | +--------------------------+ +----------------------+ | | + | | ^ ^ | | + | | Admin|records Application|data | | + | | | | | | + | +----------------v--------------------------v-----------+ | + | ^ | + | | ADUs | + | | | + | +-----------------------------v-------------------------+ | + | |Bundle Protocol Agent | | + | | | | + | | | | + | +-------------------------------------------------------+ | + | ^ ^ ^ | + | | Bundles | Bundles Bundles | | + | | | | | + | +------v-----+ +-----v------+ +-----v-----+ | + | |CLA 1 | |CLA 2 | |CLA n | | + | | | | | . . . | | | + | | | | | | | | + +-+------------+-----+------------+-----------+-----------+-+ + ^ ^ ^ + CL1|PDUs CL2|PDUs CLn|PDUs + | | | + +------v-----+ +-----v------+ +-----v-----+ + Network 1 Network 2 Network n + + Figure 2: Components of a Bundle Node + + Bundle Protocol Agent: The Bundle Protocol Agent (BPA) of a node is + the node component that offers the BP services and executes the + procedures of the Bundle Protocol. + + Convergence-layer adapter: A convergence-layer adapter (CLA) is a + node component that sends and receives bundles on behalf of the + BPA, utilizing the services of some "integrated" protocol stack + that is supported in one of the networks within which the node is + functionally located. + + Application agent: The application agent (AA) of a node is the node + component that utilizes the BP services to effect communication + for some user purpose. The application agent in turn has two + elements: an administrative element and an application-specific + element. + + Application-specific element: The application-specific element of an + AA is the node component that constructs, requests transmission + of, accepts delivery of, and processes units of user application + data. + + Administrative element: The administrative element of an AA is the + node component that constructs and requests transmission of + administrative records (defined below), including status reports, + and accepts delivery of and processes any administrative records + that the node receives. + + Administrative record: A BP administrative record is an ADU that is + exchanged between the administrative elements of nodes' + application agents for some BP administrative purpose. The only + administrative record defined in this specification is the status + report, discussed later. + + Bundle endpoint: A bundle endpoint (or simply "endpoint") is a set + of zero or more bundle nodes that all identify themselves for BP + purposes by some common identifier, called a "bundle endpoint ID" + (or, in this document, simply "endpoint ID"); endpoint IDs are + described in detail in Section 4.2.5.1. + + Singleton endpoint: A singleton endpoint is an endpoint that always + contains exactly one member. + + Registration: A registration is the state machine characterizing a + given node's membership in a given endpoint. Any single + registration has an associated delivery failure action as defined + below and must at any time be in one of two states: Active or + Passive. Registrations are local; information about a node's + registrations is not expected to be available at other nodes, and + the Bundle Protocol does not include a mechanism for distributing + information about registrations. + + Delivery: A bundle is considered to have been delivered at a node + subject to a registration as soon as the ADU that is the payload + of the bundle, together with any relevant metadata (an + implementation matter), has been presented to the node's + application agent in a manner consistent with the state of that + registration. + + Deliverability: A bundle is considered "deliverable" subject to a + registration if and only if (a) the bundle's destination endpoint + is the endpoint with which the registration is associated, (b) the + bundle has not yet been delivered subject to this registration, + and (c) the bundle has not yet been "abandoned" (as defined below) + subject to this registration. + + Abandonment: To abandon a bundle subject to some registration is to + assert that the bundle is not deliverable subject to that + registration. + + Delivery failure action: The delivery failure action of a + registration is the action that is to be taken when a bundle that + is "deliverable" subject to that registration is received at a + time when the registration is in the Passive state. + + Destination: The destination of a bundle is the endpoint comprising + the node(s) at which the bundle is to be delivered (as defined + above). + + Transmission: A transmission is an attempt by a node's BPA to cause + copies of a bundle to be delivered to one or more of the nodes + that are members of some endpoint (the bundle's destination) in + response to a transmission request issued by the node's + application agent. + + Forwarding: To forward a bundle to a node is to invoke the services + of one or more CLAs in a sustained effort to cause a copy of the + bundle to be received by that node. + + Discarding: To discard a bundle is to cease all operations on the + bundle and functionally erase all references to it. The specific + procedures by which this is accomplished are an implementation + matter. + + Retention constraint: A retention constraint is an element of the + state of a bundle that prevents the bundle from being discarded. + That is, a bundle cannot be discarded while it has any retention + constraints. + + Deletion: To delete a bundle is to remove unconditionally all of the + bundle's retention constraints, enabling the bundle to be + discarded. + +3.2. Discussion of BP Concepts + + Multiple instances of the same bundle (the same unit of DTN protocol + data) might exist concurrently in different parts of a network -- + possibly differing in some blocks -- in the memory local to one or + more bundle nodes and/or in transit between nodes. In the context of + the operation of a bundle node, a bundle is an instance (copy), in + that node's local memory, of some bundle that is in the network. + + The payload for a bundle forwarded in response to a bundle + transmission request is the ADU whose location is provided as a + parameter to that request. The payload for a bundle forwarded in + response to reception of a bundle is the payload of the received + bundle. + + In the most familiar case, a bundle node is instantiated as a single + process running on a general-purpose computer, but in general the + definition is meant to be broader: a bundle node might alternatively + be a thread, an object in an object-oriented operating system, a + special-purpose hardware device, etc. + + The manner in which the functions of the BPA are performed is wholly + an implementation matter. For example, BPA functionality might be + coded into each node individually; it might be implemented as a + shared library that is used in common by any number of bundle nodes + on a single computer; it might be implemented as a daemon whose + services are invoked via inter-process or network communication by + any number of bundle nodes on one or more computers; it might be + implemented in hardware. + + Every CLA implements its own thin layer of protocol, interposed + between BP and the (usually "top") protocol(s) of the underlying + integrated protocol stack; this "CL protocol" may only serve to + multiplex and demultiplex bundles to and from the underlying + integrated protocol, or it may offer additional CL-specific + functionality. The manner in which a CLA sends and receives bundles, + as well as the definitions of CLAs and CL protocols, are beyond the + scope of this specification. + + Note that the administrative element of a node's application agent + may itself, in some cases, function as a CLA. That is, outgoing + bundles may be "tunneled" through encapsulating bundles: + + * 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. + + 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: + + * 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 + +3.3. Services Offered by Bundle Protocol Agents + + The BPA of each node is expected to provide the following services to + the node's application agent: + + * 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. + + Note that the details of registration functionality are an + implementation matter and are beyond the scope of this specification. + +4. Bundle Format + +4.1. Bundle Structure + + The format of bundles SHALL conform to the Concise Binary Object + Representation (CBOR) [RFC8949]. + + Cryptographic verification of a block is possible only if the + sequence of octets on which the verifying node computes its hash -- + the canonicalized representation of the block -- is identical to the + sequence of octets on which the hash declared for that block was + computed. To ensure that blocks are always in canonical + representation when they are transmitted and received, the CBOR + encodings of the values of all fields in all blocks MUST conform to + the core deterministic encoding requirements as specified in + [RFC8949], except that indefinite-length items are not prohibited. + + Each bundle SHALL be a concatenated sequence of at least two blocks, + represented as a CBOR indefinite-length array. The first block in + the sequence (the first item of the array) MUST be a primary bundle + block in CBOR encoding as described below; the bundle MUST have + exactly one primary bundle block. The primary block MUST be followed + by one or more canonical bundle blocks (additional array items) in + CBOR encoding as described in Section 4.3.2. Every block following + the primary block SHALL be the CBOR encoding of a canonical block. + The last such block MUST be a payload block; the bundle MUST have + exactly one payload block. The payload block SHALL be followed by a + CBOR "break" stop code, terminating the array. + + | (Note that, while CBOR permits considerable flexibility in the + | encoding of bundles, this flexibility must not be interpreted + | as inviting increased complexity in PDU structure.) + + Associated with each block of a bundle is a block number. The block + number uniquely identifies the block within the bundle, enabling + blocks (notably Bundle Protocol Security blocks) to reference other + blocks in the same bundle without ambiguity. The block number of the + primary block is implicitly zero; the block numbers of all other + blocks are explicitly stated in block headers as noted below. Block + numbering is unrelated to the order in which blocks are sequenced in + the bundle. The block number of the payload block is always 1. + + An implementation of the Bundle Protocol MAY discard any sequence of + bytes that does not conform to the Bundle Protocol specification. + + An implementation of the Bundle Protocol MAY accept a sequence of + bytes that does not conform to the Bundle Protocol specification + (e.g., one that represents data elements in fixed-length arrays + rather than indefinite-length arrays) and transform it into + conformant BP structure before processing it. Procedures for + accomplishing such a transformation are beyond the scope of this + specification. + +4.2. BP Fundamental Data Structures + +4.2.1. CRC Type + + CRC type is an unsigned integer type code for which the following + values (and no others) are valid: + + * 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." + [RFC4960] + + 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]. + +4.2.2. CRC + + 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. + +4.2.3. Bundle Processing Control Flags + + 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: + + * 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. + + 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): + + 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. + +4.2.4. Block Processing Control Flags + + 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): + + 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. + + 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. + +4.2.5. Identifiers + +4.2.5.1. Endpoint ID + + 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. + +4.2.5.1.1. The dtn URI Scheme + + The "dtn" scheme supports the identification of BP endpoints by + arbitrarily expressive character strings. It is specified as + follows: + + Scheme syntax: This specification uses the Augmented Backus-Naur + Form (ABNF) notation of [RFC5234]. + + 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. + + 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. + + 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. + +4.2.5.1.2. The ipn URI Scheme + + 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: + + Scheme syntax: This specification uses the Augmented Backus-Naur + Form (ABNF) notation of [RFC5234], 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. + + 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. + + 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. + +4.2.5.2. Node ID + + 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: + + * 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. + +4.2.6. DTN Time + + 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 (2^32 - 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. + +4.2.7. Creation Timestamp + + 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). + +4.2.8. Block-Type-Specific Data + + 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. + +4.3. Block Structures + + This section describes the primary block in detail and non-primary + blocks in general. Rules for processing these blocks appear in + Section 5. + + Note that supplementary DTN protocol specifications (including, but + not restricted to, Bundle Protocol Security [BPSEC]) may require that + BP implementations conforming to those protocols construct and + process additional blocks. + +4.3.1. Primary Bundle Block + + 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: + + 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. + +4.3.2. Canonical Bundle Block Format + + 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: + + 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. + +4.4. Extension Blocks + + "Extension blocks" are all blocks other than the primary and payload + blocks. Three types of extension blocks are defined below. All + implementations of the Bundle Protocol specification (the present + document) MUST include procedures for recognizing, parsing, and + acting on, but not necessarily producing, these types of extension + blocks. + + The specifications for additional types of extension blocks must + indicate whether or not BP implementations conforming to those + specifications must recognize, parse, act on, and/or produce blocks + of those types. As not all nodes will necessarily instantiate BP + implementations that conform to those additional specifications, it + is possible for a node to receive a bundle that includes extension + blocks that the node cannot process. The values of the block + processing control flags indicate the action to be taken by the BPA + when this is the case. + + No mandated procedure in this specification is unconditionally + dependent on the absence or presence of any extension block. + Therefore, any BPA MAY insert or remove any extension block in any + bundle, subject to all mandates in the Bundle Protocol specification + and all extension block specifications to which the node's BP + implementation conforms. Note that removal of an extension block + will probably disable one or more elements of bundle processing that + were intended by the BPA that inserted that block. In particular, + note that removal of an extension block that is one of the targets of + a BPSec security block may render the bundle unverifiable. + + The following extension blocks are defined in the current document. + +4.4.1. Previous Node + + 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. + +4.4.2. Bundle Age + + 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. + +4.4.3. Hop Count + + 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. + +5. Bundle Processing + + 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. + +5.1. Generation of Administrative Records + + All transmission of bundles is in response to bundle transmission + requests presented by nodes' application agents. When required to + "generate" an administrative record (such as a bundle status report), + the BPA itself is responsible for causing a new bundle to be + transmitted, conveying that record. In concept, the BPA discharges + this responsibility by directing the administrative element of the + node's application agent to construct the record and request its + transmission as detailed in Section 6. In practice, the manner in + which administrative record generation is accomplished is an + implementation matter, provided the constraints noted in Section 6 + are observed. + + Status reports are relatively small bundles. Moreover, even when the + generation of status reports is enabled, the decision on whether or + not to generate a requested status report is left to the discretion + of the BPA. Nonetheless, note that requesting status reports for any + single bundle might easily result in the generation of (1 + (2 + *(N-1))) status report bundles, where N is the number of nodes on the + path from the bundle's source to its destination, inclusive. That + is, the requesting of status reports for large numbers of bundles + could result in an unacceptable increase in the bundle traffic in the + network. For this reason, the generation of status reports MUST be + disabled by default and enabled only when the risk of excessive + network traffic is deemed acceptable. Mechanisms that could assist + in assessing and mitigating this risk, such as pre-placed agreements + authorizing the generation of status reports under specified + circumstances, are beyond the scope of this specification. + + Notes on administrative record terminology: + + * 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. + +5.2. Bundle Transmission + + The steps in processing a bundle transmission request are as follows: + + Step 1: Transmission of the bundle is initiated. An outbound bundle + MUST be created per the parameters of the bundle + transmission request, with the retention constraint + "Dispatch pending". The source node ID of the bundle MUST + be either (a) the null endpoint ID, indicating that the + source of the bundle is anonymous or (b) the EID of a + singleton endpoint whose only member is the node of which + the BPA is a component. + + Step 2: Processing proceeds from Step 1 of Section 5.4. + +5.3. Bundle Dispatching + + (Note that this procedure is initiated only following completion of + Step 4 of Section 5.6.) + + The steps in dispatching a bundle are as follows: + + Step 1: If the bundle's destination endpoint is an endpoint of which + the node is a member, the Bundle Delivery procedure defined + in Section 5.7 MUST be followed and, for the purposes of all + subsequent processing of this bundle at this node, the + node's membership in the bundle's destination endpoint SHALL + be disavowed; specifically, even though the node is a member + of the bundle's destination endpoint, the node SHALL NOT + undertake to forward the bundle to itself in the course of + performing the procedure described in Section 5.4. + + Step 2: Processing proceeds from Step 1 of Section 5.4. + +5.4. Bundle Forwarding + + The steps in forwarding a bundle are as follows: + + Step 1: The retention constraint "Forward pending" MUST be added to + the bundle, and the bundle's "Dispatch pending" retention + constraint MUST be removed. + + Step 2: The BPA MUST determine whether or not forwarding is + contraindicated (that is, rendered inadvisable) for any of + the reasons listed in the IANA "Bundle Status Report Reason + Codes" registry (see Section 9.5), whose initial contents + are listed in Table 1. In particular: + + * The BPA MAY choose to either forward the bundle directly + to its destination node(s) (if possible) or forward the + bundle to some other node(s) for further forwarding. The + manner in which this decision is made may depend on the + scheme name in the destination endpoint ID and/or on + other state but in any case is beyond the scope of this + document; one possible mechanism is described in [SABR]. + If the BPA elects to forward the bundle to some other + node(s) for further forwarding but finds it impossible to + select any node(s) to forward the bundle to, then + forwarding is contraindicated. + + * Provided the BPA succeeded in selecting the node or nodes + to forward the bundle to, the BPA MUST subsequently + select the CLA(s) whose services will enable the node to + send the bundle to those nodes. The manner in which + specific appropriate CLAs are selected is beyond the + scope of this document; the TCP CLA [TCPCL] MUST be + implemented when some or all of the bundles forwarded by + the BPA must be forwarded via the Internet but may not be + appropriate for the forwarding of any particular bundle. + If the agent finds it impossible to select any + appropriate CLA(s) to use in forwarding this bundle, then + forwarding is contraindicated. + + Step 3: If forwarding of the bundle is determined to be + contraindicated for any of the reasons listed in the IANA + "Bundle Status Report Reason Codes" registry (see + Section 9.5), then the Forwarding Contraindicated procedure + defined in Section 5.4.1 MUST be followed; the remaining + steps of this Bundle Forwarding procedure are skipped at + this time. + + Step 4: For each node selected for forwarding, the BPA MUST invoke + the services of the selected CLA(s) in order to effect the + sending of the bundle to that node. Determining the time at + which the BPA invokes CLA services is a BPA implementation + matter. Determining the time at which each CLA subsequently + responds to this service invocation by sending the bundle is + a CLA implementation matter. Note that: + + * If the bundle has a Previous Node Block, as defined in + Section 4.4.1, then that block MUST be removed from the + bundle before the bundle is forwarded. + + * If the BPA is configured to attach Previous Node Blocks + to forwarded bundles, then a Previous Node Block + containing the node ID of the forwarding node MUST be + inserted into the bundle before the bundle is forwarded. + + * If the bundle has a Bundle Age Block, as defined in + Section 4.4.2, then at the last possible moment before + the CLA initiates conveyance of the bundle via the CL + protocol the bundle age value MUST be increased by the + difference between the current time and the time at which + the bundle was received (or, if the local node is the + source of the bundle, created). + + Step 5: When all selected CLAs have informed the BPA that they have + concluded their data-sending procedures with regard to this + bundle, processing may depend on the results of those + procedures. + + If completion of the data-sending procedures by all selected CLAs has + not resulted in successful forwarding of the bundle (an + implementation-specific determination that is beyond the scope of + this specification), then the BPA MAY choose (in an implementation- + specific manner, again beyond the scope of this specification) to + initiate another attempt to forward the bundle. In that event, + processing proceeds from Step 4. The minimum number of times a given + node will initiate another forwarding attempt for any single bundle + in this event (a number that may be zero) is a node configuration + parameter that must be exposed to other nodes in the network to the + extent that this is required by the operating environment. + + If completion of the data-sending procedures by all selected CLAs + *HAS* resulted in successful forwarding of the bundle, or if it has + not but the BPA does not choose to initiate another attempt to + forward the bundle, then: + + * 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. + +5.4.1. Forwarding Contraindicated + + The steps in responding to contraindication of forwarding are as + follows: + + 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. + + Otherwise, when -- at some future time -- the forwarding of this + bundle ceases to be contraindicated, processing proceeds from Step 4 + of Section 5.4. + +5.4.2. Forwarding Failed + + The steps in responding to a declaration of forwarding failure are as + follows: + + 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. + +5.5. Bundle Expiration + + A bundle expires when the bundle's age exceeds its lifetime as + specified in the primary bundle block or as overridden by the BPA. + Bundle age MAY be determined by subtracting the bundle's creation + timestamp time from the current time if (a) that timestamp time is + not zero and (b) the local node's clock is known to be accurate; + otherwise, bundle age MUST be obtained from the Bundle Age extension + block. Bundle expiration MAY occur at any point in the processing of + a bundle. When a bundle expires, the BPA MUST delete the bundle for + the reason "Lifetime expired" (when the expired lifetime is the + lifetime as specified in the primary block) or "Traffic pared" (when + the expired lifetime is a lifetime override as imposed by the BPA): + the Bundle Deletion procedure defined in Section 5.10 MUST be + followed. + +5.6. Bundle Reception + + The steps in processing a bundle that has been received from another + node are as follows: + + Step 1: The retention constraint "Dispatch pending" MUST be added to + the bundle. + + Step 2: If the "request reporting of bundle reception" flag in the + bundle's status report request field is set to 1 and status + reporting is enabled, then a bundle reception status report + with reason code "No additional information" SHOULD be + generated, destined for the bundle's report-to endpoint ID. + + Step 3: CRCs SHOULD be computed for every block of the bundle that + has an attached CRC. If any block of the bundle is + malformed according to this specification (including + syntactically invalid CBOR), or if any block has an attached + CRC and the CRC computed for this block upon reception + differs from that attached CRC, then the BPA MUST delete the + bundle for the reason "Block unintelligible". The Bundle + Deletion procedure defined in Section 5.10 MUST be followed, + and all remaining steps of the Bundle Reception procedure + MUST be skipped. + + Step 4: For each block in the bundle that is an extension block that + the BPA cannot process: + + * If the block processing control flags in that block + indicate that a status report is requested in this event + and if status reporting is enabled, then a bundle + reception status report with reason code "Block + unsupported" SHOULD be generated, destined for the + bundle's report-to endpoint ID. + + * If the block processing control flags in that block + indicate that the bundle must be deleted in this event, + then the BPA MUST delete the bundle for the reason "Block + unsupported"; the Bundle Deletion procedure defined in + Section 5.10 MUST be followed, and all remaining steps of + the Bundle Reception procedure MUST be skipped. + + * If the block processing control flags in that block do + *NOT* indicate that the bundle must be deleted in this + event but do indicate that the block must be discarded, + then the BPA MUST remove this block from the bundle. + + * If the block processing control flags in that block + neither indicate that the bundle must be deleted nor + indicate that the block must be discarded, then + processing continues with the next extension block that + the BPA cannot process, if any; otherwise, processing + proceeds from Step 5. + + Step 5: Processing proceeds from Step 1 of Section 5.3. + +5.7. Local Bundle Delivery + + The steps in processing a bundle that is destined for an endpoint of + which this node is a member are as follows: + + Step 1: If the received bundle is a fragment, the ADU Reassembly + procedure described in Section 5.9 MUST be followed. If + this procedure results in reassembly of the entire original + ADU, processing of the fragmentary bundle whose payload has + been replaced by the reassembled ADU (whether this bundle or + a previously received fragment) proceeds from Step 2; + otherwise, the retention constraint "Reassembly pending" + MUST be added to the bundle, and all remaining steps of this + procedure MUST be skipped. + + Step 2: Delivery depends on the state of the registration whose + endpoint ID matches that of the destination of the bundle: + + * An additional implementation-specific delivery deferral + procedure MAY optionally be associated with the + registration. + + * If the registration is in the Active state, then the + bundle MUST be delivered automatically as soon as it is + the next bundle that is due for delivery according to the + BPA's bundle delivery scheduling policy (an + implementation matter). + + * If the registration is in the Passive state, or if + delivery of the bundle fails for some implementation- + specific reason, then the registration's delivery failure + action MUST be taken. The delivery failure action MUST + be one of the following: + + - Defer delivery of the bundle subject to this + registration until (a) this bundle is the least + recently received of all bundles currently deliverable + subject to this registration and (b) either the + registration is polled or the registration is in the + Active state, and also perform any additional delivery + deferral procedure associated with the registration, + or + + - Abandon delivery of the bundle subject to this + registration (as defined in Section 3.1). + + Step 3: As soon as the bundle has been delivered, if the "request + reporting of bundle delivery" flag in the bundle's status + report request field is set to 1 and bundle status reporting + is enabled, then a bundle delivery status report SHOULD be + generated, destined for the bundle's report-to endpoint ID. + Note that this status report only states that the payload + has been delivered to the application agent, not that the + application agent has processed that payload. + +5.8. Bundle Fragmentation + + It may at times be advantageous for BPAs to reduce the sizes of + bundles in order to forward them. This might be the case, for + example, if a node to which a bundle is to be forwarded is accessible + only via intermittent contacts and no upcoming contact is long enough + to enable the forwarding of the entire bundle. + + The size of a bundle can be reduced by "fragmenting" the bundle. To + fragment a bundle whose payload is of size M is to replace it with + two "fragments" -- new bundles with the same source node ID and + creation timestamp as the original bundle -- whose payloads MUST be + the first N and the last (M - N) bytes of the original bundle's + payload, where 0 < N < M. + + Note that fragments are bundles and therefore may themselves be + fragmented, so multiple episodes of fragmentation may in effect + replace the original bundle with more than two fragments. (However, + there is only one "level" of fragmentation, as in IP fragmentation.) + + Any bundle whose primary block's bundle processing control flags do + *NOT* indicate that it must not be fragmented MAY be fragmented at + any time, for any purpose, at the discretion of the BPA. *NOTE*, + however, that some combinations of bundle fragmentation, replication, + and routing might result in unexpected traffic patterns. + + Fragmentation SHALL be constrained as follows: + + * 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. + +5.9. Application Data Unit Reassembly + + Note that the Bundle Fragmentation procedure described in Section 5.8 + may result in the replacement of a single original bundle with an + arbitrarily large number of fragmentary bundles. In order to be + delivered at a destination node, the original bundle's payload must + be reassembled from the payloads of those fragments. + + The "material extents" of a received fragment's payload are all + continuous sequences of bytes in that payload that do not overlap + with the material extents of the payloads of any previously received + fragments with the same source node ID and creation timestamp. If + the concatenation -- as informed by fragment offsets and payload + lengths -- of the material extents of the payloads of this fragment + and all previously received fragments with the same source node ID + and creation timestamp as this fragment forms a continuous byte array + whose length is equal to the total application data unit length noted + in the fragment's primary block, then: + + * 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. + + Note: Reassembly of ADUs from fragments occurs at the nodes that are + members of destination endpoints as necessary; an ADU MAY also be + reassembled at some other node on the path to the destination. + +5.10. Bundle Deletion + + The steps in deleting a bundle are as follows: + + Step 1: If the "request reporting of bundle deletion" flag in the + bundle's status report request field is set to 1 and if + status reporting is enabled, then a bundle deletion status + report citing the reason for deletion SHOULD be generated, + destined for the bundle's report-to endpoint ID. + + Step 2: All of the bundle's retention constraints MUST be removed. + +5.11. Discarding a Bundle + + As soon as a bundle has no remaining retention constraints, it MAY be + discarded, thereby releasing any persistent storage that may have + been allocated to it. + +5.12. Canceling a Transmission + + When requested to cancel a specified transmission, where the bundle + created upon initiation of the indicated transmission has not yet + been discarded, the BPA MUST delete that bundle for the reason + "Transmission canceled". For this purpose, the procedure defined in + Section 5.10 MUST be followed. + +6. Administrative Record Processing + +6.1. Administrative Records + + Administrative records are standard ADUs that are used in providing + some of the features of the Bundle Protocol. Bundle Protocol + administrative record types are registered in the IANA "Bundle + Administrative Record Types" registry [RFC5050]; of these, only + administrative record type 1, "Bundle status report", is defined for + BPv7 at this time. Note that additional types of administrative + records may be defined by supplementary DTN protocol specification + documents. + + Every administrative record consists of: + + * A record type code (an unsigned integer for which valid values are + as defined below). + + * Record content in type-specific format. + + Each BP administrative record SHALL be represented as a CBOR array + comprising two items. + + The first item of the array SHALL be a record type code, which SHALL + be represented as a CBOR unsigned integer. + + The second element of this array SHALL be the applicable CBOR + encoding of the content of the record. Details of the CBOR encoding + of administrative record type 1 are provided below. Details of the + CBOR encoding of other types of administrative records are included + in the specifications defining those records. + +6.1.1. Bundle Status Reports + + 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: + + * Reporting node received bundle. + + * Reporting node forwarded the bundle. + + * Reporting node delivered the bundle. + + * Reporting node deleted the bundle. + + 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 | + +--------+--------------------------------------------+ + + Table 1: Status Report Reason Codes + + 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. + +6.2. Generation of Administrative Records + + Whenever the application agent's administrative element is directed + by the BPA to generate an administrative record, the following + procedure must be followed: + + Step 1: The administrative record must be constructed. If the + administrative record references a bundle and the referenced + bundle is a fragment, the administrative record MUST contain + the fragment offset and fragment length. + + Step 2: A request for transmission of a bundle whose payload is this + administrative record MUST be presented to the BPA. + +7. Services Required of the Convergence Layer + +7.1. The Convergence Layer + + The successful operation of the end-to-end Bundle Protocol depends on + the operation of underlying protocols at what is termed the + "convergence layer"; these protocols accomplish communication between + nodes. A wide variety of protocols may serve this purpose, so long + as each CLA provides a defined minimal set of services to the BPA. + This convergence-layer service specification enumerates those + services. + +7.2. Summary of Convergence-Layer Services + + Each CLA is expected to provide the following services to the BPA: + + * 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. + + 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. + +8. Security Considerations + + 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. + +9. IANA Considerations + + The Bundle Protocol includes fields requiring registries managed by + IANA. + +9.1. Bundle Block Types + + The "Bundle Block Types" subregistry in the "Bundle Protocol" + registry has been augmented by adding a column identifying the + version of the Bundle Protocol (Bundle Protocol Version) that applies + to the values. IANA has added the following values, as described in + Section 4.3.1, to the "Bundle Block Types" registry with a value of + "7" for the Bundle Protocol Version. IANA has set the Bundle + Protocol Version to "6" or "6,7" for preexisting values in the + "Bundle Block Types" registry, as shown below. + + +=================+=========+=========================+===========+ + | Bundle Protocol | Value | Description | Reference | + | Version | | | | + +=================+=========+=========================+===========+ + | none | 0 | Reserved | [RFC6255] | + +-----------------+---------+-------------------------+-----------+ + | 6,7 | 1 | Bundle Payload Block | [RFC5050] | + | | | | [RFC9171] | + +-----------------+---------+-------------------------+-----------+ + | 6 | 2 | Bundle Authentication | [RFC6257] | + | | | Block | | + +-----------------+---------+-------------------------+-----------+ + | 6 | 3 | Payload Integrity Block | [RFC6257] | + +-----------------+---------+-------------------------+-----------+ + | 6 | 4 | Payload Confidentiality | [RFC6257] | + | | | Block | | + +-----------------+---------+-------------------------+-----------+ + | 6 | 5 | Previous-Hop Insertion | [RFC6259] | + | | | Block | | + +-----------------+---------+-------------------------+-----------+ + | 7 | 6 | Previous node | [RFC9171] | + | | | (proximate sender) | | + +-----------------+---------+-------------------------+-----------+ + | 7 | 7 | Bundle age (in | [RFC9171] | + | | | milliseconds) | | + +-----------------+---------+-------------------------+-----------+ + | 6 | 8 | Metadata Extension | [RFC6258] | + | | | Block | | + +-----------------+---------+-------------------------+-----------+ + | 6 | 9 | Extension Security | [RFC6257] | + | | | Block | | + +-----------------+---------+-------------------------+-----------+ + | 7 | 10 | Hop count (#prior xmit | [RFC9171] | + | | | attempts) | | + +-----------------+---------+-------------------------+-----------+ + | 7 | 11-191 | Unassigned | | + +-----------------+---------+-------------------------+-----------+ + | 6,7 | 192-255 | Reserved for Private | [RFC5050] | + | | | and/or Experimental Use | [RFC9171] | + +-----------------+---------+-------------------------+-----------+ + + Table 2: "Bundle Block Types" Registry + +9.2. Primary Bundle Protocol Version + + IANA has added the following value to the "Primary Bundle Protocol + Version" subregistry in the "Bundle Protocol" registry. + + +=======+=============+===========+ + | Value | Description | Reference | + +=======+=============+===========+ + | 7 | Assigned | [RFC9171] | + +-------+-------------+-----------+ + + Table 3: "Primary Bundle + Protocol Version" Registry + + Values 8-255 (rather than 7-255) are now Unassigned. + +9.3. Bundle Processing Control Flags + + The "Bundle Processing Control Flags" subregistry in the "Bundle + Protocol" registry has been augmented by adding a column identifying + the version of the Bundle Protocol (Bundle Protocol Version) that + applies to the new values. IANA has added the following values, as + described in Section 4.2.3, to the "Bundle Processing Control Flags" + registry with a value of "7" for the Bundle Protocol Version. IANA + has set the Bundle Protocol Version to the value "6" or "6,7" for + preexisting values in the "Bundle Processing Control Flags" registry, + as shown below. + + +=================+=================+===================+===========+ + | Bundle Protocol | Bit Position | Description | Reference | + | Version | (right to | | | + | | left) | | | + +=================+=================+===================+===========+ + | 6,7 | 0 | Bundle is a | [RFC5050] | + | | | fragment | [RFC9171] | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 1 | ADU is an | [RFC5050] | + | | | administrative | [RFC9171] | + | | | record | | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 2 | Bundle must not | [RFC5050] | + | | | be fragmented | [RFC9171] | + +-----------------+-----------------+-------------------+-----------+ + | 6 | 3 | Custody transfer | [RFC5050] | + | | | is requested | | + +-----------------+-----------------+-------------------+-----------+ + | 6 | 4 | Destination | [RFC5050] | + | | | endpoint is a | | + | | | singleton | | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 5 | Acknowledgement | [RFC5050] | + | | | by application is | [RFC9171] | + | | | requested | | + +-----------------+-----------------+-------------------+-----------+ + | 7 | 6 | Status time | [RFC9171] | + | | | requested in | | + | | | reports | | + +-----------------+-----------------+-------------------+-----------+ + | 6 | 7-8 | Class of service: | [RFC5050] | + | | | priority | | + +-----------------+-----------------+-------------------+-----------+ + | 6 | 9-13 | Class of service: | [RFC5050] | + | | | reserved | | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 14 | Request reporting | [RFC5050] | + | | | of bundle | [RFC9171] | + | | | reception | | + +-----------------+-----------------+-------------------+-----------+ + | 6 | 15 | Request reporting | [RFC5050] | + | | | of custody | | + | | | acceptance | | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 16 | Request reporting | [RFC5050] | + | | | of bundle | [RFC9171] | + | | | forwarding | | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 17 | Request reporting | [RFC5050] | + | | | of bundle | [RFC9171] | + | | | delivery | | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 18 | Request reporting | [RFC5050] | + | | | of bundle | [RFC9171] | + | | | deletion | | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 19 | Reserved | [RFC5050] | + | | | | [RFC9171] | + +-----------------+-----------------+-------------------+-----------+ + | 6,7 | 20 | Reserved | [RFC5050] | + | | | | [RFC9171] | + +-----------------+-----------------+-------------------+-----------+ + | | 21-63 | Unassigned | | + +-----------------+-----------------+-------------------+-----------+ + + Table 4: "Bundle Processing Control Flags" Registry + +9.4. Block Processing Control Flags + + The "Block Processing Control Flags" subregistry in the "Bundle + Protocol" registry has been augmented by adding a column identifying + the version of the Bundle Protocol (Bundle Protocol Version) that + applies to the related BP version. IANA has set the Bundle Protocol + Version to the value "6" or "6,7" for preexisting values in the + "Bundle Processing Control Flags" registry, as shown below. + + +=================+==============+====================+===========+ + | Bundle Protocol | Bit Position | Description | Reference | + | Version | (right to | | | + | | left) | | | + +=================+==============+====================+===========+ + | 6,7 | 0 | Block must be | [RFC5050] | + | | | replicated in | [RFC9171] | + | | | every fragment | | + +-----------------+--------------+--------------------+-----------+ + | 6,7 | 1 | Transmit status | [RFC5050] | + | | | report if block | [RFC9171] | + | | | can't be processed | | + +-----------------+--------------+--------------------+-----------+ + | 6,7 | 2 | Delete bundle if | [RFC5050] | + | | | block can't be | [RFC9171] | + | | | processed | | + +-----------------+--------------+--------------------+-----------+ + | 6 | 3 | Last block | [RFC5050] | + +-----------------+--------------+--------------------+-----------+ + | 6,7 | 4 | Discard block if | [RFC5050] | + | | | it can't be | [RFC9171] | + | | | processed | | + +-----------------+--------------+--------------------+-----------+ + | 6 | 5 | Block was | [RFC5050] | + | | | forwarded without | | + | | | being processed | | + +-----------------+--------------+--------------------+-----------+ + | 6 | 6 | Block contains an | [RFC5050] | + | | | EID-reference | | + | | | field | | + +-----------------+--------------+--------------------+-----------+ + | | 7-63 | Unassigned | | + +-----------------+--------------+--------------------+-----------+ + + Table 5: "Block Processing Control Flags" Registry + +9.5. Bundle Status Report Reason Codes + + The "Bundle Status Report Reason Codes" subregistry in the "Bundle + Protocol" registry has been augmented by adding a column identifying + the version of the Bundle Protocol (Bundle Protocol Version) that + applies to the new values. IANA has added the following values, as + described in Section 6.1.1, to the "Bundle Status Report Reason + Codes" registry with a value of "7" for the Bundle Protocol Version. + IANA has set the Bundle Protocol Version to the value "6,7" for + preexisting values in the "Bundle Status Report Reason Codes" + registry, as shown below. + + +=================+========+========================+===========+ + | Bundle Protocol | Value | Description | Reference | + | Version | | | | + +=================+========+========================+===========+ + | 6,7 | 0 | No additional | [RFC5050] | + | | | information | [RFC9171] | + +-----------------+--------+------------------------+-----------+ + | 6,7 | 1 | Lifetime expired | [RFC5050] | + | | | | [RFC9171] | + +-----------------+--------+------------------------+-----------+ + | 6,7 | 2 | Forwarded over | [RFC5050] | + | | | unidirectional link | [RFC9171] | + +-----------------+--------+------------------------+-----------+ + | 6,7 | 3 | Transmission canceled | [RFC5050] | + | | | | [RFC9171] | + +-----------------+--------+------------------------+-----------+ + | 6,7 | 4 | Depleted storage | [RFC5050] | + | | | | [RFC9171] | + +-----------------+--------+------------------------+-----------+ + | 6,7 | 5 | Destination endpoint | [RFC5050] | + | | | ID unavailable | [RFC9171] | + +-----------------+--------+------------------------+-----------+ + | 6,7 | 6 | No known route to | [RFC5050] | + | | | destination from here | [RFC9171] | + +-----------------+--------+------------------------+-----------+ + | 6,7 | 7 | No timely contact with | [RFC5050] | + | | | next node on route | [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] | + +-----------------+--------+------------------------+-----------+ + + Table 6: "Bundle Status Report Reason Codes" Registry + +9.6. Bundle Protocol URI Scheme Types + + The Bundle Protocol has a URI scheme type field -- an unsigned + integer of indefinite length -- for which IANA has created, and will + maintain, a new "Bundle Protocol URI Scheme Types" subregistry in the + "Bundle Protocol" registry. The "Bundle Protocol URI Scheme Types" + registry governs a namespace of unsigned integers. Initial values + for the "Bundle Protocol URI Scheme Types" registry are given below. + + The registration policy for this registry is Standards Action + [RFC8126]. The allocation should only be granted for a Standards + Track RFC approved by the IESG. + + The range of values is provided as unsigned integers. + + Each assignment consists of a URI scheme type name and its associated + description, a reference to the document that defines the URI scheme, + and a reference to the document that defines the use of this URI + scheme in BP endpoint IDs (including the CBOR encoding of those + endpoint IDs in transmitted bundles). + + +===========+==============+================+================+ + | Value | Description | BP Utilization | URI Definition | + | | | Reference | 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 | n/a | | + | | Private Use | | | + +-----------+--------------+----------------+----------------+ + + Table 7: "Bundle Protocol URI Scheme Types" Registry + +9.7. dtn URI Scheme + + In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) + registry, IANA has updated the registration of the URI scheme with + the string "dtn" as the scheme name, as follows: + + URI scheme name: "dtn" + + Status: Permanent + + Applications and/or protocols that use this URI scheme name: The + Delay-Tolerant Networking (DTN) Bundle Protocol (BP). + + Contact: Scott Burleigh <sburleig.sb@gmail.com> + + Change controller: IETF (iesg@ietf.org) + + Reference: [RFC9171] + +9.8. ipn URI Scheme + + In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes) + registry, IANA has updated the registration of the URI scheme with + the string "ipn" as the scheme name, originally documented in RFC + 6260 [RFC6260], as follows. + + URI scheme name: "ipn" + + Status: Permanent + + Applications and/or protocols that use this URI scheme name: The + Delay-Tolerant Networking (DTN) Bundle Protocol (BP). + + Contact: Scott Burleigh <sburleig.sb@gmail.com> + + Change controller: IETF (iesg@ietf.org) + + Reference: [RFC9171] + +10. References + +10.1. Normative References + + [BPSEC] Birrane, III, E. 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", p. 9, + Section 2.2.7.4, ITU-T Recommendation X.25, October 1996, + <https://www.itu.int/rec/T-REC-X.25-199610-I/>. + + [RFC2119] Bradner, S., "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] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + <https://www.rfc-editor.org/info/rfc4960>. + + [RFC5234] Crocker, D., Ed. 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] Leiba, B., "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] Bormann, C. 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] Sipos, B., Demmer, M., Ott, J., 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] Berners-Lee, T., Fielding, R., 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] Thaler, D., Ed., Hansen, T., 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>. + +10.2. Informative References + + [ARCH] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, + R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant + Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, + April 2007, <https://www.rfc-editor.org/info/rfc4838>. + + [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in + Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 + February 2020, <https://datatracker.ietf.org/doc/html/ + draft-ietf-dtn-bibect-03>. + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, + January 2005, <https://www.rfc-editor.org/info/rfc3987>. + + [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol + Specification", RFC 5050, DOI 10.17487/RFC5050, November + 2007, <https://www.rfc-editor.org/info/rfc5050>. + + [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol + IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May + 2011, <https://www.rfc-editor.org/info/rfc6255>. + + [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, + "Bundle Security Protocol Specification", RFC 6257, + DOI 10.17487/RFC6257, May 2011, + <https://www.rfc-editor.org/info/rfc6257>. + + [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata + Extension Block", RFC 6258, DOI 10.17487/RFC6258, May + 2011, <https://www.rfc-editor.org/info/rfc6258>. + + [RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop + Insertion Block", RFC 6259, DOI 10.17487/RFC6259, May + 2011, <https://www.rfc-editor.org/info/rfc6259>. + + [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", + RFC 6260, DOI 10.17487/RFC6260, May 2011, + <https://www.rfc-editor.org/info/rfc6260>. + + [RFC7143] Chadalapaka, M., Satran, J., Meth, K., 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] Cotton, M., Leiba, B., 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] Fall, K., "A Delay-Tolerant Network Architecture for + Challenged Internets", SIGCOMM 2003, + DOI 10.1145/863955.863960, August 2003, + <https://dl.acm.org/doi/10.1145/863955.863960>. + +Appendix A. Significant Changes from RFC 5050 + + This document makes the following significant changes from RFC 5050: + + * 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. + +Appendix B. CDDL Expression + + 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 + + ] + +Acknowledgments + + 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. + +Authors' Addresses + + Scott Burleigh + IPNGROUP + 1435 Woodhurst Blvd. + McLean, VA 22102 + United States of America + + Email: sburleig.sb@gmail.com + + + Kevin Fall + Roland Computing Services + 3871 Piedmont Ave. Suite 8 + Oakland, CA 94611 + United States of America + + Email: kfall+rcs@kfall.com + + + Edward J. Birrane, III + Johns Hopkins University Applied Physics Laboratory + 11100 Johns Hopkins Rd + Laurel, MD 20723 + United States of America + + Phone: +1 443 778 7423 + Email: Edward.Birrane@jhuapl.edu |