rfc9171.original   rfc9171.txt 
Delay-Tolerant Networking Working Group S. Burleigh
Internet Draft JPL, Calif. Inst. Of Technology
Intended status: Standards Track K. Fall
Expires: July 29, 2021 Roland Computing Services
E. Birrane
APL, Johns Hopkins University
January 25, 2021
Bundle Protocol Version 7 Internet Engineering Task Force (IETF) S. Burleigh
draft-ietf-dtn-bpbis-31.txt 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
Status of this Memo Bundle Protocol Version 7
This Internet-Draft is submitted in full conformance with the Abstract
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document presents a specification for the Bundle Protocol,
Task Force (IETF), its areas, and its working groups. Note that adapted from the experimental Bundle Protocol specification developed
other groups may also distribute working documents as Internet- by the Delay-Tolerant Networking Research Group of the Internet
Drafts. Research Task Force and documented in RFC 5050.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (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.
This Internet-Draft will expire on July 29, 2021. 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 Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Revised BSD License text as described in Section 4.e of the
Section 4.e of the Trust Legal Provisions and are provided without Trust Legal Provisions and are provided without warranty as described
warranty as described in the Simplified BSD License. in the Revised BSD License.
Abstract
This Internet Draft 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.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction
2. Conventions used in this document..............................5 2. Conventions Used in This Document
3. Service Description............................................5 3. Service Description
3.1. Definitions...............................................5 3.1. Definitions
3.2. Discussion of BP concepts.................................9 3.2. Discussion of BP Concepts
3.3. Services Offered by Bundle Protocol Agents...............12 3.3. Services Offered by Bundle Protocol Agents
4. Bundle Format.................................................13 4. Bundle Format
4.1. Bundle Structure.........................................13 4.1. Bundle Structure
4.2. BP Fundamental Data Structures...........................14 4.2. BP Fundamental Data Structures
4.2.1. CRC Type............................................14 4.2.1. CRC Type
4.2.2. CRC.................................................14 4.2.2. CRC
4.2.3. Bundle Processing Control Flags.....................15 4.2.3. Bundle Processing Control Flags
4.2.4. Block Processing Control Flags......................16 4.2.4. Block Processing Control Flags
4.2.5. Identifiers.........................................17 4.2.5. Identifiers
4.2.5.1. Endpoint ID....................................17 4.2.5.1. Endpoint ID
4.2.5.1.1. The "dtn" URI scheme......................18 4.2.5.1.1. The dtn URI Scheme
4.2.5.1.2. The "ipn" URI scheme......................20 4.2.5.1.2. The ipn URI Scheme
4.2.5.2. Node ID........................................22 4.2.5.2. Node ID
4.2.6. DTN Time............................................22 4.2.6. DTN Time
4.2.7. Creation Timestamp..................................22 4.2.7. Creation Timestamp
4.2.8. Block-type-specific Data............................23 4.2.8. Block-Type-Specific Data
4.3. Block Structures.........................................23 4.3. Block Structures
4.3.1. Primary Bundle Block................................23 4.3.1. Primary Bundle Block
4.3.2. Canonical Bundle Block Format.......................26 4.3.2. Canonical Bundle Block Format
4.4. Extension Blocks.........................................27 4.4. Extension Blocks
4.4.1. Previous Node.......................................27 4.4.1. Previous Node
4.4.2. Bundle Age..........................................28 4.4.2. Bundle Age
4.4.3. Hop Count...........................................28 4.4.3. Hop Count
5. Bundle Processing.............................................29 5. Bundle Processing
5.1. Generation of Administrative Records.....................29 5.1. Generation of Administrative Records
5.2. Bundle Transmission......................................30 5.2. Bundle Transmission
5.3. Bundle Dispatching.......................................30 5.3. Bundle Dispatching
5.4. Bundle Forwarding........................................30 5.4. Bundle Forwarding
5.4.1. Forwarding Contraindicated..........................33 5.4.1. Forwarding Contraindicated
5.4.2. Forwarding Failed...................................33 5.4.2. Forwarding Failed
5.5. Bundle Expiration........................................33 5.5. Bundle Expiration
5.6. Bundle Reception.........................................34 5.6. Bundle Reception
5.7. Local Bundle Delivery....................................35 5.7. Local Bundle Delivery
5.8. Bundle Fragmentation.....................................36 5.8. Bundle Fragmentation
5.9. Application Data Unit Reassembly.........................37 5.9. Application Data Unit Reassembly
5.10. Bundle Deletion.........................................38 5.10. Bundle Deletion
5.11. Discarding a Bundle.....................................38 5.11. Discarding a Bundle
5.12. Canceling a Transmission................................38 5.12. Canceling a Transmission
6. Administrative Record Processing..............................38 6. Administrative Record Processing
6.1. Administrative Records...................................38 6.1. Administrative Records
6.1.1. Bundle Status Reports...............................39 6.1.1. Bundle Status Reports
6.2. Generation of Administrative Records.....................42 6.2. Generation of Administrative Records
7. Services Required of the Convergence Layer....................43 7. Services Required of the Convergence Layer
7.1. The Convergence Layer....................................43 7.1. The Convergence Layer
7.2. Summary of Convergence Layer Services....................43 7.2. Summary of Convergence-Layer Services
8. Implementation Status.........................................44 8. Security Considerations
9. Security Considerations.......................................45 9. IANA Considerations
10. IANA Considerations..........................................47 9.1. Bundle Block Types
10.1. Bundle Block Types......................................47 9.2. Primary Bundle Protocol Version
10.2. Primary Bundle Protocol Version.........................48 9.3. Bundle Processing Control Flags
10.3. Bundle Processing Control Flags.........................49 9.4. Block Processing Control Flags
10.4. Block Processing Control Flags..........................51 9.5. Bundle Status Report Reason Codes
10.5. Bundle Status Report Reason Codes.......................52 9.6. Bundle Protocol URI Scheme Types
10.6. Bundle Protocol URI scheme types........................53 9.7. dtn URI Scheme
10.7. URI scheme "dtn"........................................54 9.8. ipn URI Scheme
10.8. URI scheme "ipn"........................................55 10. References
11. References...................................................56 10.1. Normative References
11.1. Normative References....................................56 10.2. Informative References
11.2. Informative References..................................56 Appendix A. Significant Changes from RFC 5050
12. Acknowledgments..............................................57 Appendix B. CDDL Expression
13. Significant Changes from RFC 5050............................58 Acknowledgments
Appendix A. For More Information.................................59 Authors' Addresses
Appendix B. CDDL expression......................................60
1. Introduction 1. Introduction
Since the publication of the Bundle Protocol Specification Since the publication of the Bundle Protocol specification
(Experimental RFC 5050 [RFC5050]) in 2007, the Delay-Tolerant (Experimental RFC 5050 [RFC5050]) in 2007, the Delay-Tolerant
Networking (DTN) Bundle Protocol has been implemented in multiple Networking (DTN) Bundle Protocol (BP) has been implemented in
programming languages and deployed to a wide variety of computing multiple programming languages and deployed to a wide variety of
platforms. This implementation and deployment experience has computing platforms. This implementation and deployment experience
identified opportunities for making the protocol simpler, more has identified opportunities for making the protocol simpler, more
capable, and easier to use. The present document, standardizing the capable, and easier to use. The present document, standardizing the
Bundle Protocol (BP), is adapted from RFC 5050 in that context, Bundle Protocol, is adapted from RFC 5050 in that context, reflecting
reflecting lessons learned. Significant changes from the Bundle lessons learned. Significant changes from the Bundle Protocol
Protocol specification defined in RFC 5050 are listed in section 13. specification defined in RFC 5050 are listed in Appendix A.
This document describes version 7 of BP. This document describes BP version 7 (BPv7).
Delay Tolerant Networking is a network architecture providing Delay-Tolerant Networking is a network architecture providing
communications in and/or through highly stressed environments. communications in and/or through highly stressed environments.
Stressed networking environments include those with intermittent Stressed networking environments include those with intermittent
connectivity, large and/or variable delays, and high bit error connectivity, large and/or variable delays, and high bit error rates.
rates. To provide its services, BP may be viewed as sitting at the To provide its services, BP may be viewed as sitting at the
application layer of some number of constituent networks, forming a application layer of some number of constituent networks, forming a
store-carry-forward overlay network. Key capabilities of BP store-carry-forward overlay network. Key capabilities of BP include:
include:
. Ability to use physical motility for the movement of data * 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 move the responsibility for error control from one node
. Ability to cope with intermittent connectivity, including cases to another.
where the sender and receiver are not concurrently present in
the network * Ability to cope with intermittent connectivity, including cases
. Ability to take advantage of scheduled, predicted, and where the sender and receiver are not concurrently present in the
opportunistic connectivity, whether bidirectional or network.
unidirectional, in addition to continuous connectivity
. Late binding of overlay network endpoint identifiers to * Ability to take advantage of scheduled, predicted, and
underlying constituent network addresses 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 For descriptions of these capabilities and the rationale for the DTN
architecture, see [ARCH] and [SIGC]. architecture, see [ARCH] and [SIGC].
BP's location within the standard protocol stack is as shown in BP's location within the standard protocol stack is as shown in
Figure 1. BP uses underlying "native" transport and/or network Figure 1. BP uses underlying "integrated" transport and/or network
protocols for communications within a given constituent network. protocols for communications within a given constituent network. The
The layer at which those underlying protocols are located is here layer at which those underlying protocols are located is here termed
termed the "convergence layer" and the interface between the bundle the "convergence layer", and the interface between the Bundle
protocol and a specific underlying protocol is termed a "convergence Protocol and a specific underlying protocol is termed a "convergence-
layer adapter". layer adapter".
Figure 1 shows three distinct transport and network protocols Figure 1 shows three distinct transport and network protocols
(denoted T1/N1, T2/N2, and T3/N3). (denoted T1/N1, T2/N2, and T3/N3).
+-----------+ +-----------+ +-----------+ +-----------+
| BP app | | BP app | | BP app | | BP app |
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| BP v | | ^ BP v | | ^ BP v | | ^ BP | | BP v | | ^ BP v | | ^ BP v | | ^ BP |
+---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+
skipping to change at page 5, line 14 skipping to change at line 188
| N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 | | N1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ N3 |
+---------v-+ +-^---------v + +-^---------v-+ +-^---------+ +---------v-+ +-^---------v + +-^---------v-+ +-^---------+
| >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ |
+-----------+ +-------------+ +-------------+ +-----------+ +-----------+ +-------------+ +-------------+ +-----------+
| | | | | | | |
|<---- A network ---->| |<---- A network ---->| |<---- A network ---->| |<---- A network ---->|
| | | | | | | |
Figure 1: The Bundle Protocol in the Protocol Stack Model Figure 1: The Bundle Protocol in the Protocol Stack Model
This document describes the format of the protocol data units This document describes the format of the protocol data units (PDUs)
(called "bundles") passed between entities participating in BP (called "bundles") passed between entities participating in BP
communications. communications.
The entities are referred to as "bundle nodes". This document does The entities are referred to as "bundle nodes". This document does
not address: not address:
. Operations in the convergence layer adapters that bundle nodes * Operations in the convergence-layer adapters that bundle nodes use
use to transport data through specific types of internets. to transport data through specific types of internets. (However,
(However, the document does discuss the services that must be the document does discuss the services that must be provided by
provided by each adapter at the convergence layer.) each adapter at the convergence layer.)
. The bundle route computation algorithm.
. Mechanisms for populating the routing or forwarding information * The bundle route computation algorithm.
bases of bundle nodes.
. The mechanisms for securing bundles en route. * Mechanisms for populating the routing or forwarding information
. The mechanisms for managing bundle nodes. 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 Note that implementations of the specification presented in this
document will not be interoperable with implementations of RFC 5050. document will not be interoperable with implementations of RFC 5050.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Service Description 3. Service Description
3.1. Definitions 3.1. Definitions
Bundle - A bundle is a protocol data unit of BP, so named because Bundle: A bundle is a PDU of BP, so named because negotiation of the
negotiation of the parameters of a data exchange may be impractical parameters of a data exchange may be impractical in a delay-
in a delay-tolerant network: it is often better practice to "bundle" tolerant network: it is often better practice to "bundle" with a
with a unit of application data all metadata that might be needed in unit of application data all metadata that might be needed in
order to make the data immediately usable when delivered to the order to make the data immediately usable when delivered to the
application. Each bundle comprises a sequence of two or more application. Each bundle comprises a sequence of two or more
"blocks" of protocol data, which serve various purposes. "blocks" of protocol data, which serve various purposes.
Block - A bundle protocol block is one of the protocol data Block: A Bundle Protocol block is one of the protocol data
structures that together constitute a well-formed bundle. structures that together constitute a well-formed bundle.
Application Data Unit (ADU) - An application data unit is the unit Application Data Unit: An application data unit (ADU) is the unit of
of data whose conveyance to the bundle's destination is the purpose data whose conveyance to the bundle's destination is the purpose
for the transmission of some bundle that is not a fragment (as for the transmission of some bundle that is not a fragment (as
defined below). defined below).
Bundle payload - A bundle payload (or simply "payload") is the Bundle payload: A bundle payload (or simply "payload") is the
content of the bundle's payload block. The terms "bundle content", content of the bundle's payload block. The terms "bundle
"bundle payload", and "payload" are used interchangeably in this content", "bundle payload", and "payload" are used interchangeably
document. For a bundle that is not a fragment (as defined below), in this document. For a bundle that is not a fragment (as defined
the payload is an application data unit. below), the payload is an ADU.
Partial payload - A partial payload is a payload that comprises Partial payload: A partial payload is a payload that comprises
either the first N bytes or the last N bytes of some other payload 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 of length M, such that 0 < N < M. Note that every partial payload
is a payload and therefore can be further subdivided into partial is a payload and therefore can be further subdivided into partial
payloads. payloads.
Fragment - A fragment, a.k.a. "fragmentary bundle", is a bundle Fragment: A fragment, a.k.a. "fragmentary bundle", is a bundle whose
whose payload block contains a partial payload. payload block contains a partial payload.
Bundle node - A bundle node (or, in the context of this document, 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. simply a "node") is any entity that can send and/or receive
Each bundle node has three conceptual components, defined below, as bundles. Each bundle node has three conceptual components,
shown in Figure 2: a "bundle protocol agent", a set of zero or more defined below, as shown in Figure 2: a "Bundle Protocol Agent", a
"convergence layer adapters", and an "application agent". ("CL1 set of zero or more "convergence-layer adapters", and an
PDUs" are the PDUs of the convergence-layer protocol used in network "application agent". ("CL1 PDUs" are the PDUs of the convergence-
1.) layer protocol used in network 1.)
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|Node | |Node |
| | | |
| +-------------------------------------------------------+ | | +-------------------------------------------------------+ |
| |Application Agent | | | |Application Agent | |
| | | | | | | |
| | +--------------------------+ +----------------------+ | | | | +--------------------------+ +----------------------+ | |
| | |Administrative element | |Application-specific | | | | | |Administrative element | |Application-specific | | |
| | | | |element | | | | | | | |element | | |
skipping to change at page 7, line 30 skipping to change at line 302
| | | | | | | | | | | | | | | |
+-+------------+-----+------------+-----------+-----------+-+ +-+------------+-----+------------+-----------+-----------+-+
^ ^ ^ ^ ^ ^
CL1|PDUs CL2|PDUs CLn|PDUs CL1|PDUs CL2|PDUs CLn|PDUs
| | | | | |
+------v-----+ +-----v------+ +-----v-----+ +------v-----+ +-----v------+ +-----v-----+
Network 1 Network 2 Network n Network 1 Network 2 Network n
Figure 2: Components of a Bundle Node Figure 2: Components of a Bundle Node
Bundle protocol agent - The bundle protocol agent (BPA) of a node is Bundle Protocol Agent: The Bundle Protocol Agent (BPA) of a node is
the node component that offers the BP services and executes the the node component that offers the BP services and executes the
procedures of the bundle protocol. procedures of the Bundle Protocol.
Convergence layer adapter - A convergence layer adapter (CLA) is a Convergence-layer adapter: A convergence-layer adapter (CLA) is a
node component that sends and receives bundles on behalf of the BPA, node component that sends and receives bundles on behalf of the
utilizing the services of some 'native' protocol stack that is BPA, utilizing the services of some "integrated" protocol stack
supported in one of the networks within which the node is that is supported in one of the networks within which the node is
functionally located. functionally located.
Application agent - The application agent (AA) of a node is the node Application agent: The application agent (AA) of a node is the node
component that utilizes the BP services to effect communication for component that utilizes the BP services to effect communication
some user purpose. The application agent in turn has two elements, for some user purpose. The application agent in turn has two
an administrative element and an application-specific element. elements: an administrative element and an application-specific
element.
Application-specific element - The application-specific element of Application-specific element: The application-specific element of an
an AA is the node component that constructs, requests transmission AA is the node component that constructs, requests transmission
of, accepts delivery of, and processes units of user application of, accepts delivery of, and processes units of user application
data. data.
Administrative element - The administrative element of an AA is the Administrative element: The administrative element of an AA is the
node component that constructs and requests transmission of node component that constructs and requests transmission of
administrative records (defined below), including status reports, administrative records (defined below), including status reports,
and accepts delivery of and processes any administrative records and accepts delivery of and processes any administrative records
that the node receives. that the node receives.
Administrative record - A BP administrative record is an application Administrative record: A BP administrative record is an ADU that is
data unit that is exchanged between the administrative elements of exchanged between the administrative elements of nodes'
nodes' application agents for some BP administrative purpose. The application agents for some BP administrative purpose. The only
only administrative record defined in this specification is the administrative record defined in this specification is the status
status report, discussed later. report, discussed later.
Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set Bundle endpoint: A bundle endpoint (or simply "endpoint") is a set
of zero or more bundle nodes that all identify themselves for BP of zero or more bundle nodes that all identify themselves for BP
purposes by some common identifier, called a "bundle endpoint ID" purposes by some common identifier, called a "bundle endpoint ID"
(or, in this document, simply "endpoint ID"; endpoint IDs are (or, in this document, simply "endpoint ID"); endpoint IDs are
described in detail in Section 4.5.5.1 below. described in detail in Section 4.2.5.1.
Singleton endpoint - A singleton endpoint is an endpoint that always Singleton endpoint: A singleton endpoint is an endpoint that always
contains exactly one member. contains exactly one member.
Registration - A registration is the state machine characterizing a Registration: A registration is the state machine characterizing a
given node's membership in a given endpoint. Any single given node's membership in a given endpoint. Any single
registration has an associated delivery failure action as defined registration has an associated delivery failure action as defined
below and must at any time be in one of two states: Active or below and must at any time be in one of two states: Active or
Passive. Registrations are local; information about a node's Passive. Registrations are local; information about a node's
registrations is not expected to be available at other nodes, and registrations is not expected to be available at other nodes, and
the Bundle Protocol does not include a mechanism for distributing the Bundle Protocol does not include a mechanism for distributing
information about registrations. information about registrations.
Delivery - A bundle is considered to have been delivered at a node Delivery: A bundle is considered to have been delivered at a node
subject to a registration as soon as the application data unit that subject to a registration as soon as the ADU that is the payload
is the payload of the bundle, together with any relevant metadata of the bundle, together with any relevant metadata (an
(an implementation matter), has been presented to the node's implementation matter), has been presented to the node's
application agent in a manner consistent with the state of that application agent in a manner consistent with the state of that
registration. registration.
Deliverability - A bundle is considered "deliverable" subject to a Deliverability: A bundle is considered "deliverable" subject to a
registration if and only if (a) the bundle's destination endpoint is registration if and only if (a) the bundle's destination endpoint
the endpoint with which the registration is associated, (b) the is the endpoint with which the registration is associated, (b) the
bundle has not yet been delivered subject to this registration, and bundle has not yet been delivered subject to this registration,
(c) the bundle has not yet been "abandoned" (as defined below) and (c) the bundle has not yet been "abandoned" (as defined below)
subject to this registration. subject to this registration.
Abandonment - To abandon a bundle subject to some registration is to Abandonment: To abandon a bundle subject to some registration is to
assert that the bundle is not deliverable subject to that assert that the bundle is not deliverable subject to that
registration. registration.
Delivery failure action - The delivery failure action of a Delivery failure action: The delivery failure action of a
registration is the action that is to be taken when a bundle that is registration is the action that is to be taken when a bundle that
"deliverable" subject to that registration is received at a time is "deliverable" subject to that registration is received at a
when the registration is in the Passive state. time when the registration is in the Passive state.
Destination - The destination of a bundle is the endpoint comprising Destination: The destination of a bundle is the endpoint comprising
the node(s) at which the bundle is to be delivered (as defined the node(s) at which the bundle is to be delivered (as defined
above). above).
Transmission - A transmission is an attempt by a node's BPA to cause 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 copies of a bundle to be delivered to one or more of the nodes
are members of some endpoint (the bundle's destination) in response that are members of some endpoint (the bundle's destination) in
to a transmission request issued by the node's application agent. 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 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 of one or more CLAs in a sustained effort to cause a copy of the
bundle to be received by that node. bundle to be received by that node.
Discarding - To discard a bundle is to cease all operations on the Discarding: To discard a bundle is to cease all operations on the
bundle and functionally erase all references to it. The specific bundle and functionally erase all references to it. The specific
procedures by which this is accomplished are an implementation procedures by which this is accomplished are an implementation
matter. matter.
Retention constraint - A retention constraint is an element of the Retention constraint: A retention constraint is an element of the
state of a bundle that prevents the bundle from being discarded. state of a bundle that prevents the bundle from being discarded.
That is, a bundle cannot be discarded while it has any retention That is, a bundle cannot be discarded while it has any retention
constraints. constraints.
Deletion - To delete a bundle is to remove unconditionally all of Deletion: To delete a bundle is to remove unconditionally all of the
the bundle's retention constraints, enabling the bundle to be bundle's retention constraints, enabling the bundle to be
discarded. discarded.
3.2. Discussion of BP concepts 3.2. Discussion of BP Concepts
Multiple instances of the same bundle (the same unit of DTN protocol Multiple instances of the same bundle (the same unit of DTN protocol
data) might exist concurrently in different parts of a network -- data) might exist concurrently in different parts of a network --
possibly differing in some blocks -- in the memory local to one or 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 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 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. that node's local memory, of some bundle that is in the network.
The payload for a bundle forwarded in response to a bundle The payload for a bundle forwarded in response to a bundle
transmission request is the application data unit whose location is transmission request is the ADU whose location is provided as a
provided as a parameter to that request. The payload for a bundle parameter to that request. The payload for a bundle forwarded in
forwarded in response to reception of a bundle is the payload of the response to reception of a bundle is the payload of the received
received bundle. bundle.
In the most familiar case, a bundle node is instantiated as a single In the most familiar case, a bundle node is instantiated as a single
process running on a general-purpose computer, but in general the process running on a general-purpose computer, but in general the
definition is meant to be broader: a bundle node might alternatively definition is meant to be broader: a bundle node might alternatively
be a thread, an object in an object-oriented operating system, a be a thread, an object in an object-oriented operating system, a
special-purpose hardware device, etc. special-purpose hardware device, etc.
The manner in which the functions of the BPA are performed is wholly The manner in which the functions of the BPA are performed is wholly
an implementation matter. For example, BPA functionality might be an implementation matter. For example, BPA functionality might be
coded into each node individually; it might be implemented as a coded into each node individually; it might be implemented as a
shared library that is used in common by any number of bundle nodes 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 on a single computer; it might be implemented as a daemon whose
services are invoked via inter-process or network communication by services are invoked via inter-process or network communication by
any number of bundle nodes on one or more computers; it might be any number of bundle nodes on one or more computers; it might be
implemented in hardware. implemented in hardware.
Every CLA implements its own thin layer of protocol, interposed Every CLA implements its own thin layer of protocol, interposed
between BP and the (usually "top") protocol(s) of the underlying between BP and the (usually "top") protocol(s) of the underlying
native protocol stack; this "CL protocol" may only serve to integrated protocol stack; this "CL protocol" may only serve to
multiplex and de-multiplex bundles to and from the underlying native multiplex and demultiplex bundles to and from the underlying
protocol, or it may offer additional CL-specific functionality. The integrated protocol, or it may offer additional CL-specific
manner in which a CLA sends and receives bundles, as well as the functionality. The manner in which a CLA sends and receives bundles,
definitions of CLAs and CL protocols, are beyond the scope of this as well as the definitions of CLAs and CL protocols, are beyond the
specification. scope of this specification.
Note that the administrative element of a node's application agent Note that the administrative element of a node's application agent
may itself, in some cases, function as a convergence-layer adapter. may itself, in some cases, function as a CLA. That is, outgoing
That is, outgoing bundles may be "tunneled" through encapsulating bundles may be "tunneled" through encapsulating bundles:
bundles:
. An outgoing bundle constitutes a byte array. This byte array * An outgoing bundle constitutes a byte array. This byte array may,
may, like any other, be presented to the bundle protocol agent like any other, be presented to the BPA as an ADU that is to be
as an application data unit that is to be transmitted to some transmitted to some endpoint.
endpoint.
. The original bundle thus forms the payload of an encapsulating * The original bundle thus forms the payload of an encapsulating
bundle that is forwarded using some other convergence-layer bundle that is forwarded using some other convergence-layer
protocol(s). protocol(s).
. When the encapsulating bundle is received, its payload is
delivered to the peer application agent administrative element, * When the encapsulating bundle is received, its payload is
which then instructs the bundle protocol agent to dispatch that delivered to the peer application agent administrative element,
original bundle in the usual way. 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- The purposes for which this technique may be useful (such as cross-
domain security) are beyond the scope of this specification. domain security) are beyond the scope of this specification.
The only interface between the BPA and the application-specific The only interface between the BPA and the application-specific
element of the AA is the BP service interface. But between the BPA element of the AA is the BP service interface. But between the BPA
and the administrative element of the AA there is a (conceptual) and the administrative element of the AA there is a (conceptual)
private control interface in addition to the BP service interface. private control interface in addition to the BP service interface.
This private control interface enables the BPA and the This private control interface enables the BPA and the administrative
administrative element of the AA to direct each other to take action element of the AA to direct each other to take action under specific
under specific circumstances. circumstances.
In the case of a node that serves simply as a BP "router", the AA In the case of a node that serves simply as a BP "router", the AA may
may have no application-specific element at all. The application- have no application-specific element at all. The application-
specific elements of other nodes' AAs may perform arbitrarily specific elements of other nodes' AAs may perform arbitrarily complex
complex application functions, perhaps even offering multiplexed DTN application functions, perhaps even offering multiplexed DTN
communication services to a number of other applications. As with communication services to a number of other applications. As with
the BPA, the manner in which the AA performs its functions is wholly the BPA, the manner in which the AA performs its functions is wholly
an implementation matter. an implementation matter.
Singletons are the most familiar sort of endpoint, but in general Singletons are the most familiar sort of endpoint, but in general the
the endpoint notion is meant to be broader. For example, the nodes endpoint notion is meant to be broader. For example, the nodes in a
in a sensor network might constitute a set of bundle nodes that are sensor network might constitute a set of bundle nodes that are all
all registered in a single common endpoint and will all receive any registered in a single common endpoint and will all receive any data
data delivered at that endpoint. *Note* too that any given bundle delivered at that endpoint. *Note* too that any given bundle node
node might be registered in multiple bundle endpoints and receive might be registered in multiple bundle endpoints and receive all data
all data delivered at each of those endpoints. delivered at each of those endpoints.
Recall that every node, by definition, includes an application agent Recall that every node, by definition, includes an application agent,
which in turn includes an administrative element, which exchanges which in turn includes an administrative element, which exchanges
administrative records with the administrative elements of other administrative records with the administrative elements of other
nodes. As such, every node is permanently, structurally registered nodes. As such, every node is permanently, structurally registered
in the singleton endpoint at which administrative records received in the singleton endpoint at which administrative records received
from other nodes are delivered. Registration in no other endpoint from other nodes are delivered. Registration in no other endpoint
can ever be assumed to be permanent. This endpoint, termed the can ever be assumed to be permanent. This endpoint, termed the
node's "administrative endpoint", is therefore uniquely and node's "administrative endpoint", is therefore uniquely and
permanently associated with the node, and for this reason the ID of permanently associated with the node, and for this reason the ID of a
a node's administrative endpoint additionally serves as the "node node's administrative endpoint may always serve as the "node ID" (see
ID" (see 4.1.5.2 below) of the node. Section 4.2.5.2) of the node.
The destination of every bundle is an endpoint, which may or may not 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 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 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 bundle may be the null endpoint ID (as described later) rather than
the ID of the source node; bundles for which the asserted source the ID of the source node; bundles for which the asserted source node
node ID is the null endpoint ID are termed "anonymous" bundles. ID is the null endpoint ID are termed "anonymous" bundles.
Any number of transmissions may be concurrently undertaken by the Any number of transmissions may be concurrently undertaken by the BPA
bundle protocol agent of a given node. of a given node.
When the bundle protocol agent of a node determines that a bundle When the BPA of a node determines that it must forward a bundle
must be forwarded to a node (either to a node that is a member of either to a node that is a member of the bundle's destination
the bundle's destination endpoint or to some intermediate forwarding endpoint or to some intermediate forwarding node, the BPA invokes the
node) in the course of completing the successful transmission of services of one or more CLAs in a sustained effort to cause a copy of
that bundle, the bundle protocol agent invokes the services of one the bundle to be received by that node.
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 that has been received by Upon reception, the processing of a bundle depends on whether or not
a given node depends on whether or not the receiving node is the receiving node is registered in the bundle's destination
registered in the bundle's destination endpoint. If it is, and if endpoint. If it is, and if the payload of the bundle is non-
the payload of the bundle is non-fragmentary (possibly as a result fragmentary (possibly as a result of successful payload reassembly
of successful payload reassembly from fragmentary payloads, from fragmentary payloads, including the original payload of the
including the original payload of the newly received bundle), then newly received bundle), then the bundle is normally delivered to the
the bundle is normally delivered to the node's application agent node's application agent subject to the registration characterizing
subject to the registration characterizing the node's membership in the node's membership in the destination endpoint.
the destination endpoint.
The bundle protocol does not natively ensure delivery of a bundle to The Bundle Protocol itself does not ensure delivery of a bundle to
its destination. Data loss along the path to the destination node its destination. Data loss along the path to the destination node
can be minimized by utilizing reliable convergence-layer protocols can be minimized by utilizing reliable convergence-layer protocols
between neighbors on all segments of the end-to-end path, but for between neighbors on all segments of the end-to-end path; however,
end-to-end bundle delivery assurance it will be necessary to develop for end-to-end bundle delivery assurance it will be necessary to
extensions to the bundle protocol and/or application-layer develop extensions to the Bundle Protocol and/or application-layer
mechanisms. mechanisms.
The bundle protocol is designed for extensibility. Bundle protocol The Bundle Protocol is designed for extensibility. Bundle Protocol
extensions, documented elsewhere, may extend this specification by: extensions, documented elsewhere, may extend this specification by
defining additional:
. defining additional blocks; * blocks
. defining additional administrative records;
. defining additional bundle processing flags;
. defining additional block processing flags;
. defining additional types of bundle status reports;
. defining additional bundle status report reason codes;
. defining additional mandates and constraints on processing
that conformant bundle protocol agents must perform at
specified points in the inbound and outbound bundle processing
cycles.
3.3. Services Offered by Bundle Protocol Agents * administrative records
The BPA of each node is expected to provide the following services * bundle processing control flags
to the node's application agent:
. commencing a registration (registering the node in an * block processing control flags
endpoint);
. terminating a registration; * types of bundle status reports
. switching a registration between Active and Passive states;
. transmitting a bundle to an identified bundle endpoint; * bundle status report reason codes
. canceling a transmission;
. polling a registration that is in the Passive state; * mandates and constraints on processing that conformant BPAs must
. delivering a received bundle. 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 Note that the details of registration functionality are an
implementation matter and are beyond the scope of this implementation matter and are beyond the scope of this specification.
specification.
4. Bundle Format 4. Bundle Format
4.1. Bundle Structure 4.1. Bundle Structure
The format of bundles SHALL conform to the Concise Binary Object The format of bundles SHALL conform to the Concise Binary Object
Representation (CBOR [RFC8949]). Representation (CBOR) [RFC8949].
Cryptographic verification of a block is possible only if the Cryptographic verification of a block is possible only if the
sequence of octets on which the verifying node computes its hash - sequence of octets on which the verifying node computes its hash --
the canonicalized representation of the block - is identical to the the canonicalized representation of the block -- is identical to the
sequence of octets on which the hash declared for that block was sequence of octets on which the hash declared for that block was
computed. To ensure that blocks are always in canonical computed. To ensure that blocks are always in canonical
representation when they are transmitted and received, the CBOR representation when they are transmitted and received, the CBOR
representations of the values of all fields in all blocks must encodings of the values of all fields in all blocks MUST conform to
conform to the rules for Canonical CBOR as specified in [RFC8949]. 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, Each bundle SHALL be a concatenated sequence of at least two blocks,
represented as a CBOR indefinite-length array. The first block in represented as a CBOR indefinite-length array. The first block in
the sequence (the first item of the array) MUST be a primary bundle the sequence (the first item of the array) MUST be a primary bundle
block in CBOR representation as described below; the bundle MUST block in CBOR encoding as described below; the bundle MUST have
have exactly one primary bundle block. The primary block MUST be exactly one primary bundle block. The primary block MUST be followed
followed by one or more canonical bundle blocks (additional array by one or more canonical bundle blocks (additional array items) in
items) in CBOR representation as described in 4.3.2 below. Every CBOR encoding as described in Section 4.3.2. Every block following
block following the primary block SHALL be the CBOR representation the primary block SHALL be the CBOR encoding of a canonical block.
of a canonical block. The last such block MUST be a payload block; The last such block MUST be a payload block; the bundle MUST have
the bundle MUST have exactly one payload block. The payload block exactly one payload block. The payload block SHALL be followed by a
SHALL be followed by a CBOR "break" stop code, terminating the CBOR "break" stop code, terminating the array.
array.
(Note that, while CBOR permits considerable flexibility in the | (Note that, while CBOR permits considerable flexibility in the
encoding of bundles, this flexibility must not be interpreted as | encoding of bundles, this flexibility must not be interpreted
inviting increased complexity in protocol data unit structure.) | as inviting increased complexity in PDU structure.)
Associated with each block of a bundle is a block number. The block Associated with each block of a bundle is a block number. The block
number uniquely identifies the block within the bundle, enabling number uniquely identifies the block within the bundle, enabling
blocks (notably bundle security protocol blocks) to reference other blocks (notably Bundle Protocol Security blocks) to reference other
blocks in the same bundle without ambiguity. The block number of blocks in the same bundle without ambiguity. The block number of the
the primary block is implicitly zero; the block numbers of all other primary block is implicitly zero; the block numbers of all other
blocks are explicitly stated in block headers as noted below. Block blocks are explicitly stated in block headers as noted below. Block
numbering is unrelated to the order in which blocks are sequenced in numbering is unrelated to the order in which blocks are sequenced in
the bundle. The block number of the payload block is always 1. the bundle. The block number of the payload block is always 1.
An implementation of the Bundle Protocol MAY discard any sequence of An implementation of the Bundle Protocol MAY discard any sequence of
bytes that does not conform to the Bundle Protocol specification. bytes that does not conform to the Bundle Protocol specification.
An implementation of the Bundle Protocol MAY accept a sequence of An implementation of the Bundle Protocol MAY accept a sequence of
bytes that does not conform to the Bundle Protocol specification bytes that does not conform to the Bundle Protocol specification
(e.g., one that represents data elements in fixed-length arrays (e.g., one that represents data elements in fixed-length arrays
rather than indefinite-length arrays) and transform it into rather than indefinite-length arrays) and transform it into
conformant BP structure before processing it. Procedures for conformant BP structure before processing it. Procedures for
accomplishing such a transformation are beyond the scope of this accomplishing such a transformation are beyond the scope of this
specification. specification.
4.2. BP Fundamental Data Structures 4.2. BP Fundamental Data Structures
4.2.1. CRC Type 4.2.1. CRC Type
CRC type is an unsigned integer type code for which the following CRC type is an unsigned integer type code for which the following
values (and no others) are valid: values (and no others) are valid:
. 0 indicates "no CRC is present." * 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." * 1 indicates "a standard X-25 CRC-16 is present." [CRC16]
[RFC4960]
* 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present."
[RFC4960]
CRC type SHALL be represented as a CBOR unsigned integer. CRC type SHALL be represented as a CBOR unsigned integer.
For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143]. For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143].
Note that more robust protection of BP data integrity, as needed, Note that more robust protection of BP data integrity, as needed, may
may be provided by means of Block Integrity Blocks as defined in the be provided by means of Block Integrity Blocks (BIBs) as defined in
Bundle Security Protocol [BPSEC]). the Bundle Protocol Security specification [BPSEC].
4.2.2. CRC 4.2.2. CRC
CRC SHALL be omitted from a block if and only if the block's CRC The CRC SHALL be omitted from a block if and only if the block's CRC
type code is zero. type code is zero.
When not omitted, the CRC SHALL be represented as a CBOR byte string 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 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 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 type is 2); in each case, the sequence of bytes SHALL constitute an
unsigned integer value (of 16 or 32 bits, respectively) in network unsigned integer value (of 16 or 32 bits, respectively) in network
byte order. byte order.
4.2.3. Bundle Processing Control Flags 4.2.3. Bundle Processing Control Flags
Bundle processing control flags assert properties of the bundle as a Bundle processing control flags assert properties of the bundle as a
whole rather than of any particular block of the bundle. They are whole rather than of any particular block of the bundle. They are
conveyed in the primary block of the bundle. conveyed in the primary block of the bundle.
The following properties are asserted by the bundle processing The following properties are asserted by the bundle processing
control flags: control flags:
. The bundle is a fragment. (Boolean) * The bundle is a fragment. (Boolean)
. The bundle's payload is an administrative record. (Boolean) * The bundle's payload is an administrative record. (Boolean)
. The bundle must not be fragmented. (Boolean) * The bundle must not be fragmented. (Boolean)
. Acknowledgment by the user application is requested. (Boolean) * Acknowledgment by the user application is requested. (Boolean)
. Status time is requested in all status reports. (Boolean) * Status time is requested in all status reports. (Boolean)
. Flags requesting types of status reports (all Boolean): * Flags requesting types of status reports (all Boolean):
o Request reporting of bundle reception. - Request reporting of bundle reception.
o Request reporting of bundle forwarding. - Request reporting of bundle forwarding.
o Request reporting of bundle delivery. - Request reporting of bundle delivery.
o Request reporting of bundle deletion. - Request reporting of bundle deletion.
If the bundle processing control flags indicate that the bundle's If the bundle processing control flags indicate that the bundle's ADU
application data unit is an administrative record, then all status is an administrative record, then all status report request flag
report request flag values MUST be zero. values MUST be zero.
If the bundle's source node is omitted (i.e., the source node ID is 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 the ID of the null endpoint, which has no members as discussed below;
below; this option enables anonymous bundle transmission), then the this option enables anonymous bundle transmission), then the bundle
bundle is not uniquely identifiable and all bundle protocol features is not uniquely identifiable and all Bundle Protocol features that
that rely on bundle identity must therefore be disabled: the "Bundle rely on bundle identity must therefore be disabled: the "Bundle must
must not be fragmented" flag value MUST be 1 and all status report not be fragmented" flag value MUST be 1, and all status report
request flag values MUST be zero. request flag values MUST be zero.
Bundle processing control flags that are unrecognized MUST be Bundle processing control flags that are unrecognized MUST be
ignored, as future definitions of additional flags might not be ignored, as future definitions of additional flags might not be
integrated simultaneously into the Bundle Protocol implementations integrated simultaneously into the Bundle Protocol implementations
operating at all nodes. operating at all nodes.
The bundle processing control flags SHALL be represented as a CBOR The bundle processing control flags SHALL be represented as a CBOR
unsigned integer item, the value of which SHALL be processed as a unsigned integer item, the value of which SHALL be processed as a bit
bit field indicating the control flag values as follows (note that field indicating the control flag values as follows (note that bit
bit numbering in this instance is reversed from the usual practice, numbering in this instance is reversed from the usual practice,
beginning with the low-order bit instead of the high-order bit, in beginning with the low-order bit instead of the high-order bit, in
recognition of the potential definition of additional control flag recognition of the potential definition of additional control flag
values in the future): values in the future):
. Bit 0 (the low-order bit, 0x000001): bundle is a fragment. Bit 0 (the low-order bit, 0x000001): Bundle is a fragment.
. Bit 1 (0x000002): payload is an administrative record.
. Bit 2 (0x000004): bundle must not be fragmented.
. Bit 3 (0x000008): reserved.
. Bit 4 (0x000010): reserved.
. Bit 5 (0x000020): user application acknowledgement is
requested.
. Bit 6 (0x000040): status time is requested in all status
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): bundle reception status reports are
requested.
. Bit 15(0x008000): reserved.
. Bit 16(0x010000): bundle forwarding status reports are
requested.
. Bit 17(0x020000): bundle delivery status reports are requested.
. Bit 18(0x040000): bundle deletion status reports are requested.
. Bits 19-20 are reserved.
. Bits 21-63 are unassigned.
4.2.4. Block Processing Control Flags 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 The block processing control flags assert properties of canonical
bundle blocks. They are conveyed in the header of the block to bundle blocks. They are conveyed in the header of the block to which
which they pertain. they pertain.
Block processing control flags that are unrecognized MUST be Block processing control flags that are unrecognized MUST be ignored,
ignored, as future definitions of additional flags might not be as future definitions of additional flags might not be integrated
integrated simultaneously into the Bundle Protocol implementations simultaneously into the Bundle Protocol implementations operating at
operating at all nodes. all nodes.
The block processing control flags SHALL be represented as a CBOR The block processing control flags SHALL be represented as a CBOR
unsigned integer item, the value of which SHALL be processed as a unsigned integer item, the value of which SHALL be processed as a bit
bit field indicating the control flag values as follows (note that field indicating the control flag values as follows (note that bit
bit numbering in this instance is reversed from the usual practice, numbering in this instance is reversed from the usual practice,
beginning with the low-order bit instead of the high-order bit, for beginning with the low-order bit instead of the high-order bit, for
agreement with the bit numbering of the bundle processing control agreement with the bit numbering of the bundle processing control
flags): flags):
. Bit 0(the low-order bit, 0x01): block must be replicated in Bit 0 (the low-order bit, 0x01): Block must be replicated in every
every fragment. fragment.
. Bit 1(0x02): transmission of a status report is requested if
block can't be processed. Bit 1 (0x02): Transmit status report if block can't be processed.
. Bit 2(0x04): bundle must be deleted if block can't be
processed. Bit 2 (0x04): Delete bundle if block can't be processed.
. Bit 3(0x08): reserved.
. Bit 4(0x10): block must be removed from bundle if it can't be Bit 3 (0x08): Reserved.
processed.
. Bit 5(0x20): reserved. Bit 4 (0x10): Discard block if it can't be processed.
. Bit 6 (0x40): reserved.
. Bits 7-63 are unassigned. Bit 5 (0x20): Reserved.
Bit 6 (0x40): Reserved.
Bits 7-63: Unassigned.
For each bundle whose bundle processing control flags indicate that For each bundle whose bundle processing control flags indicate that
the bundle's application data unit is an administrative record, or the bundle's ADU is an administrative record, or whose source node ID
whose source node ID is the null endpoint ID as defined below, the is the null endpoint ID as defined below, the value of the "Transmit
value of the "Transmit status report if block can't be processed" status report if block can't be processed" flag in every canonical
flag in every canonical block of the bundle MUST be zero. block of the bundle MUST be zero.
4.2.5. Identifiers 4.2.5. Identifiers
4.2.5.1. Endpoint ID 4.2.5.1. Endpoint ID
The destinations of bundles are bundle endpoints, identified by text The destinations of bundles are bundle endpoints, identified by text
strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID
(EID) is a Uniform Resource Identifier (URI; [URI]). As such, each (EID) is a Uniform Resource Identifier [URI]. As such, each endpoint
endpoint ID can be characterized as having this general structure: ID can be characterized as having this general structure:
< scheme name > : < scheme-specific part, or "SSP" > < scheme name > : < scheme-specific part, or "SSP" >
The scheme identified by the < scheme name > in an endpoint ID is a 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 set of syntactic and semantic rules that fully explain how to parse
and interpret the SSP. Each scheme that may be used to form a BP and interpret the scheme-specific part (SSP). Each scheme that may
endpoint ID must be added to the registry of URI scheme code numbers be used to form a BP endpoint ID must be added to the "Bundle
for Bundle Protocol maintained by IANA as described in Section 10; Protocol URI Scheme Types" registry, maintained by IANA as described
association of a unique URI scheme code number with each scheme name in Section 9.6; association of a unique URI scheme code number with
in this registry helps to enable compact representation of endpoint each scheme name in this registry helps to enable compact
IDs in bundle blocks. Note that the set of allowable schemes is representation of endpoint IDs in bundle blocks. Note that the set
effectively unlimited. Any scheme conforming to [URIREG] may be of allowable schemes is effectively unlimited. Any scheme conforming
added to the URI scheme code number registry and thereupon used in a to [URIREG] may be added to the registry of URI scheme code numbers
bundle protocol endpoint ID. and thereupon used in a Bundle Protocol endpoint ID.
Each entry in the URI scheme code number registry MUST contain a Each entry in the registry of URI scheme code numbers MUST contain a
reference to a scheme code number definition document, which defines reference to a scheme code number definition document, which defines
the manner in which the scheme-specific part of any URI formed in the manner in which the scheme-specific part of any URI formed in
that scheme is parsed and interpreted and MUST be encoded, in CBOR that scheme is parsed and interpreted and MUST be CBOR encoded for
representation, for transmission as a BP endpoint ID. The scheme transmission as a BP endpoint ID. The scheme code number definition
code number definition document may also contain information as to document may also contain information as to (a) which convergence-
(a) which convergence-layer protocol(s) may be used to forward a layer protocol(s) may be used to forward a bundle to a BP destination
bundle to a BP destination endpoint identified by such an ID, and endpoint identified by such an ID and (b) how the ID of the
(b) how the ID of the convergence-layer protocol endpoint to use for convergence-layer protocol endpoint to use for that purpose can be
that purpose can be inferred from that destination endpoint ID. inferred from that destination endpoint ID.
Note that, although endpoint IDs are URIs, implementations of the BP Note that, although endpoint IDs are URIs, implementations of the BP
service interface may support expression of endpoint IDs in some service interface may support expression of endpoint IDs in some
internationalized manner (e.g., Internationalized Resource internationalized manner (e.g., Internationalized Resource
Identifiers (IRIs); see [RFC3987]). Identifiers (IRIs); see [RFC3987]).
Each BP endpoint ID (EID) SHALL be represented as a CBOR array Each BP endpoint ID (EID) SHALL be represented as a CBOR array
comprising two items. comprising two items.
The first item of the array SHALL be the code number identifying the 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 endpoint ID's URI scheme, as defined in the registry of URI scheme
code numbers for Bundle Protocol. Each URI scheme code number SHALL code numbers for the Bundle Protocol. Each URI scheme code number
be represented as a CBOR unsigned integer. SHALL be represented as a CBOR unsigned integer.
The second item of the array SHALL be the applicable CBOR The second item of the array SHALL be the applicable CBOR encoding of
representation of the scheme-specific part (SSP) of the EID, defined the scheme-specific part of the EID, defined as noted in the
as noted in the references(s) for the URI scheme code number references(s) for the URI scheme code number registry entry for the
registry entry for the EID's URI scheme. EID's URI scheme.
4.2.5.1.1. The "dtn" URI scheme 4.2.5.1.1. The dtn URI Scheme
The "dtn" scheme supports the identification of BP endpoints by The "dtn" scheme supports the identification of BP endpoints by
arbitrarily expressive character strings. It is specified as arbitrarily expressive character strings. It is specified as
follows: follows:
Scheme syntax: This specification uses the Augmented Backus-Naur Scheme syntax: This specification uses the Augmented Backus-Naur
Form (ABNF) notation of [RFC5234]. Form (ABNF) notation of [RFC5234].
dtn-uri = "dtn:" ("none" / dtn-hier-part) dtn-uri = "dtn:" ("none" / dtn-hier-part)
dtn-hier-part = "//" node-name name-delim demux ; a path-rootless dtn-hier-part = "//" node-name name-delim demux ; a path-rootless
node-name = 1*(ALPHA/DIGIT/"-"/"."/"_") reg-name node-name = reg-name
name-delim = "/" name-delim = "/"
demux = *VCHAR demux = *VCHAR
Scheme semantics: URIs of the dtn scheme are used as endpoint
identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol Scheme semantics: URIs of the dtn scheme are used as endpoint
(BP) as described in the present document. 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 The endpoint ID "dtn:none" identifies the "null endpoint", the
endpoint that by definition never has any members. endpoint that by definition never has any members.
All BP endpoints identified by all other dtn-scheme endpoint IDs for All BP endpoints identified by all other dtn-scheme endpoint IDs for
which the first character of demux is a character other than '~' which the first character of demux is a character other than '~'
(tilde) are singleton endpoints. All BP endpoints identified by dtn- (tilde) are singleton endpoints. All BP endpoints identified by dtn-
scheme endpoint IDs for which the first character *is* '~' (tilde) scheme endpoint IDs for which the first character *is* '~' (tilde)
are *not* singleton endpoints. are *not* singleton endpoints.
A dtn-scheme endpoint ID for which the demux is of length zero MAY A dtn-scheme endpoint ID for which the demux is of length zero MAY
identify the administrative endpoint for the node identified by identify the administrative endpoint for the node identified by node-
node-name, and as such may serve as a node ID. No dtn-scheme name, and as such may serve as a node ID. No dtn-scheme endpoint ID
endpoint ID for which the demux is of non-zero length may do so. for which the demux is of non-zero length may do so.
Note that these syntactic rules impose constraints on dtn-scheme Note that these syntactic rules impose constraints on dtn-scheme
endpoint IDs that were not imposed by the original specification of endpoint IDs that were not imposed by the original specification of
the dtn scheme as provided in [RFC5050]. It is believed that the the dtn scheme as provided in [RFC5050]. It is believed that the
dtn-scheme endpoint IDs employed by BP applications conforming to dtn-scheme endpoint IDs employed by BP applications conforming to
[RFC5050] are in most cases unlikely to be in violation of these [RFC5050] are in most cases unlikely to be in violation of these
rules, but the developers of such applications are advised of the rules, but the developers of such applications are advised of the
potential for compromised interoperation. potential for compromised interoperation.
Encoding considerations: For transmission as a BP endpoint ID, the Encoding considerations: For transmission as a BP endpoint ID, the
scheme-specific part of a URI of the dtn scheme SHALL be represented scheme-specific part of a URI of the dtn scheme SHALL be
as a CBOR text string unless the EID's SSP is "none", in which case represented as a CBOR text string unless the EID's SSP is "none",
the SSP SHALL be represented as a CBOR unsigned integer with the in which case the SSP SHALL be represented as a CBOR unsigned
value zero. For all other purposes, URIs of the dtn scheme are integer with the value zero. For all other purposes, URIs of the
encoded exclusively in US-ASCII characters. dtn scheme are encoded exclusively in US-ASCII characters.
Interoperability considerations: none. Interoperability considerations: None.
Security considerations: Security considerations:
. Reliability and consistency: none of the BP endpoints Reliability and consistency: None of the BP endpoints identified
identified by the URIs of the dtn scheme are guaranteed to be by the URIs of the dtn scheme are guaranteed to be reachable at
reachable at any time, and the identity of the processing any time, and the identity of the processing entities operating
entities operating on those endpoints is never guaranteed by on those endpoints is never guaranteed by the Bundle Protocol
the Bundle Protocol itself. Bundle authentication as defined by itself. Verification of the signature provided by the Block
the Bundle Security Protocol is required for this purpose. Integrity Block targeting the bundle's primary block, as
. Malicious construction: malicious construction of a conformant defined by Bundle Protocol Security [BPSEC], is required for
dtn-scheme URI is limited to the malicious selection of node this purpose.
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 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.
The "ipn" scheme supports the identification of BP endpoints by Back-end transcoding: The limited expressiveness of URIs of the
pairs of unsigned integers, for compact representation in bundle dtn scheme effectively eliminates the possibility of threat due
blocks. It is specified as follows: to errors in back-end transcoding.
Scheme syntax: This specification uses the Augmented Backus-Naur Rare IP address formats: Not relevant, as IP addresses do not
Form (ABNF) notation of [RFC5234], including the core ABNF syntax appear anywhere in conformant dtn-scheme URIs.
rule for DIGIT defined by that specification.
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-uri = "ipn:" ipn-hier-part
ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless ipn-hier-part = node-nbr nbr-delim service-nbr ; a path-rootless
node-nbr = 1*DIGIT node-nbr = 1*DIGIT
nbr-delim = "." nbr-delim = "."
service-nbr = 1*DIGIT service-nbr = 1*DIGIT
Scheme semantics: URIs of the ipn scheme are used as endpoint Scheme semantics: URIs of the ipn scheme are used as endpoint
identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol
(BP) as described in the present document. (BP) as described in the present document.
All BP endpoints identified by ipn-scheme endpoint IDs are singleton All BP endpoints identified by ipn-scheme endpoint IDs are singleton
endpoints. endpoints.
An ipn-scheme endpoint ID for which service-nbr is zero MAY identify An ipn-scheme endpoint ID for which service-nbr is zero MAY identify
the administrative endpoint for the node identified by node-nbr, and 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 as such may serve as a node ID. No ipn-scheme endpoint ID for which
service-nbr is non-zero may do so. service-nbr is non-zero may do so.
Encoding considerations: For transmission as a BP endpoint ID, the Encoding considerations: For transmission as a BP endpoint ID, the
scheme-specific part of a URI of the ipn scheme the SSP SHALL be scheme-specific part of a URI of the ipn scheme SHALL be
represented as a CBOR array comprising two items. The first item of represented as a CBOR array comprising two items. The first item
this array SHALL be the EID's node number (a number that identifies of this array SHALL be the EID's node number (a number that
the node) represented as a CBOR unsigned integer. The second item identifies the node) represented as a CBOR unsigned integer. The
of this array SHALL be the EID's service number (a number that second item of this array SHALL be the EID's service number (a
identifies some application service) represented as a CBOR unsigned number that identifies some application service) represented as a
integer. For all other purposes, URIs of the ipn scheme are encoded CBOR unsigned integer. For all other purposes, URIs of the ipn
exclusively in US-ASCII characters. scheme are encoded exclusively in US-ASCII characters.
Interoperability considerations: none. Interoperability considerations: None.
Security considerations: Security considerations:
. Reliability and consistency: none of the BP endpoints Reliability and consistency: None of the BP endpoints identified
identified by the URIs of the ipn scheme are guaranteed to be by the URIs of the ipn scheme are guaranteed to be reachable at
reachable at any time, and the identity of the processing any time, and the identity of the processing entities operating
entities operating on those endpoints is never guaranteed by on those endpoints is never guaranteed by the Bundle Protocol
the Bundle Protocol itself. Bundle authentication as defined by itself. Verification of the signature provided by the Block
the Bundle Security Protocol [BPSEC] is required for this Integrity Block targeting the bundle's primary block, as
purpose. defined by Bundle Protocol Security [BPSEC], is required for
. Malicious construction: malicious construction of a conformant this purpose.
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 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.
For many purposes of the Bundle Protocol it is important to identify 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. the node that is operative in some context.
As discussed in 3.1 above, nodes are distinct from endpoints; As discussed in Section 3.1, nodes are distinct from endpoints;
specifically, an endpoint is a set of zero or more nodes. But specifically, an endpoint is a set of zero or more nodes. But rather
rather than define a separate namespace for node identifiers, we than define a separate namespace for node identifiers, we instead use
instead use endpoint identifiers to identify nodes as discussed in endpoint identifiers to identify nodes as discussed in Section 3.2.
3.2 above. Formally: Formally:
. Every node is, by definition, permanently registered in the * Every node is, by definition, permanently registered in the
singleton endpoint at which administrative records are singleton endpoint at which administrative records are delivered
delivered to its application agent's administrative element, to its application agent's administrative element, termed the
termed the node's "administrative endpoint". node's "administrative endpoint".
. As such, the EID of a node's administrative endpoint SHALL
uniquely identify that node.
. A "node ID" is an EID that identifies the administrative
endpoint of a node.
4.2.6. DTN Time * 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 A DTN time is an unsigned integer indicating the number of
milliseconds that have elapsed since the DTN Epoch, 2000-01-01 milliseconds that have elapsed since the DTN Epoch, 2000-01-01
00:00:00 +0000 (UTC). DTN time is not affected by leap seconds. 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. Each DTN time SHALL be represented as a CBOR unsigned integer item.
Implementers need to be aware that DTN time values conveyed in CBOR Implementers need to be aware that DTN time values conveyed in CBOR
representation in bundles will nearly always exceed (2**32 - 1); the encoding in bundles will nearly always exceed (2^32 - 1); the manner
manner in which a DTN time value is represented in memory is an in which a DTN time value is represented in memory is an
implementation matter. The DTN time value zero indicates that the implementation matter. The DTN time value zero indicates that the
time is unknown. time is unknown.
4.2.7. Creation Timestamp 4.2.7. Creation Timestamp
Each bundle's creation timestamp SHALL be represented as a CBOR Each bundle's creation timestamp SHALL be represented as a CBOR array
array comprising two items. comprising two items.
The first item of the array, termed "bundle creation time", SHALL be The first item of the array, termed "bundle creation time", SHALL be
the DTN time at which the transmission request was received that the DTN time at which the transmission request was received that
resulted in the creation of the bundle, represented as a CBOR resulted in the creation of the bundle, represented as a CBOR
unsigned integer. unsigned integer.
The second item of the array, termed the creation timestamp's The second item of the array, termed the creation timestamp's
"sequence number", SHALL be the latest value (as of the time at "sequence number", SHALL be the latest value (as of the time at which
which the transmission request was received) of a monotonically the transmission request was received) of a monotonically increasing
increasing positive integer counter managed by the source node's positive integer counter managed by the source node's BPA,
bundle protocol agent, represented as a CBOR unsigned integer. The represented as a CBOR unsigned integer. The sequence counter MAY be
sequence counter MAY be reset to zero whenever the current time reset to zero whenever the current time advances by one millisecond.
advances by one millisecond.
For nodes that lack accurate clocks, it is recommended that bundle 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 creation time be set to zero and that the counter used as the source
of the bundle sequence count never be reset to zero. of the bundle sequence count never be reset to zero.
Note that, in general, the creation of two distinct bundles with the Note that, in general, the creation of two distinct bundles with the
same source node ID and bundle creation timestamp may result in same source node ID and bundle creation timestamp may result in
unexpected network behavior and/or suboptimal performance. The unexpected network behavior and/or suboptimal performance. The
combination of source node ID and bundle creation timestamp serves combination of source node ID and bundle creation timestamp serves to
to identify a single transmission request, enabling it to be identify a single transmission request, enabling it to be
acknowledged by the receiving application (provided the source node acknowledged by the receiving application (provided the source node
ID is not the null endpoint ID). ID is not the null endpoint ID).
4.2.8. Block-type-specific Data 4.2.8. Block-Type-Specific Data
Block-type-specific data in each block (other than the primary Block-type-specific data in each block (other than the primary block)
block) SHALL be the applicable CBOR representation of the content of SHALL be the applicable CBOR encoding of the content of the block.
the block. Details of this representation are included in the Details of this representation are included in the specification
specification defining the block type. defining the block type.
4.3. Block Structures 4.3. Block Structures
This section describes the primary block in detail and non-primary This section describes the primary block in detail and non-primary
blocks in general. Rules for processing these blocks appear in blocks in general. Rules for processing these blocks appear in
Section 5 of this document. Section 5.
Note that supplementary DTN protocol specifications (including, but Note that supplementary DTN protocol specifications (including, but
not restricted to, the Bundle Security Protocol [BPSEC]) may require not restricted to, Bundle Protocol Security [BPSEC]) may require that
that BP implementations conforming to those protocols construct and BP implementations conforming to those protocols construct and
process additional blocks. process additional blocks.
4.3.1. Primary Bundle Block 4.3.1. Primary Bundle Block
The primary bundle block contains the basic information needed to The primary bundle block contains the basic information needed to
forward bundles to their destinations. forward bundles to their destinations.
Each primary block SHALL be represented as a CBOR array; the number 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 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 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 is not a fragment), 10 (if the bundle is a fragment and the block has
has no CRC), or 11 (if the bundle is a fragment and the block has a no CRC), or 11 (if the bundle is a fragment and the block has a CRC).
CRC).
The primary block of each bundle SHALL be immutable. The CBOR- The primary block of each bundle SHALL be immutable. The CBOR-
encoded values of all fields in the primary block MUST remain encoded values of all fields in the primary block MUST remain
unchanged from the time the block is created to the time it is unchanged from the time the block is created to the time it is
delivered. delivered.
The fields of the primary bundle block SHALL be as follows, listed The fields of the primary bundle block SHALL be as follows, listed in
in the order in which they MUST appear: the order in which they MUST appear:
Version: An unsigned integer value indicating the version of the Version: An unsigned integer value indicating the version of the
bundle protocol that constructed this block. The present document Bundle Protocol that constructed this block. The present document
describes version 7 of the bundle protocol. Version number SHALL be describes BPv7. This version number SHALL be represented as a
represented as a CBOR unsigned integer item. CBOR unsigned integer item.
Bundle Processing Control Flags: The Bundle Processing Control Flags Bundle Processing Control Flags: The bundle processing control flags
are discussed in Section 4.2.3. above. are discussed in Section 4.2.3.
CRC Type: CRC Type codes are discussed in Section 4.2.1. above. The CRC Type: CRC type codes are discussed in Section 4.2.1. The CRC
CRC Type code for the primary block MAY be zero if the bundle type code for the primary block MAY be zero if the bundle contains
contains a BPsec [BPSEC] Block Integrity Block whose target is the a BPSec Block Integrity Block [BPSEC] whose target is the primary
primary block; otherwise the CRC Type code for the primary block block; otherwise, the CRC type code for the primary block MUST be
MUST be non-zero. non-zero.
Destination EID: The Destination EID field identifies the bundle Destination EID: The Destination EID field identifies the bundle
endpoint that is the bundle's destination, i.e., the endpoint that endpoint that is the bundle's destination, i.e., the endpoint that
contains the node(s) at which the bundle is to be delivered. contains the node(s) at which the bundle is to be delivered.
Source node ID: The Source node ID field identifies the bundle node Source node ID: The Source node ID field identifies the bundle node
at which the bundle was initially transmitted, except that Source 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 node ID may be the null endpoint ID in the event that the bundle's
source chooses to remain anonymous. source chooses to remain anonymous.
Report-to EID: The Report-to EID field identifies the bundle Report-to EID: The Report-to EID field identifies the bundle
endpoint to which status reports pertaining to the forwarding and endpoint to which status reports pertaining to the forwarding and
delivery of this bundle are to be transmitted. delivery of this bundle are to be transmitted.
Creation Timestamp: The creation timestamp comprises two unsigned Creation Timestamp: The creation timestamp comprises two unsigned
integers that, together with the source node ID and (if the bundle integers that, together with the source node ID and (if the bundle
is a fragment) the fragment offset and payload length, serve to is a fragment) the fragment offset and payload length, serve to
identify the bundle. See 4.2.7 above for the definition of this identify the bundle. See Section 4.2.7 for the definition of this
field. field.
Lifetime: The lifetime field is an unsigned integer that indicates Lifetime: The Lifetime field is an unsigned integer that indicates
the time at which the bundle's payload will no longer be useful, the time at which the bundle's payload will no longer be useful,
encoded as a number of milliseconds past the creation time. (For encoded as a number of milliseconds past the creation time. (For
high-rate deployments with very brief disruptions, fine-grained high-rate deployments with very brief disruptions, fine-grained
expression of bundle lifetime may be useful.) When a bundle's age expression of bundle lifetime may be useful.) When a bundle's age
exceeds its lifetime, bundle nodes need no longer retain or forward exceeds its lifetime, bundle nodes need no longer retain or
the bundle; the bundle SHOULD be deleted from the network. forward the bundle; the bundle SHOULD be deleted from the network.
If the asserted lifetime for a received bundle is so lengthy that If the asserted lifetime for a received bundle is so lengthy that
retention of the bundle until its expiration time might degrade retention of the bundle until its expiration time might degrade
operation of the node at which the bundle is received, or if the operation of the node at which the bundle is received, or if the
bundle protocol agent of that node determines that the bundle must BPA of that node determines that the bundle must be deleted in
be deleted in order to prevent network performance degradation order to prevent network performance degradation (e.g., the bundle
(e.g., the bundle appears to be part of a denial-of-service attack), appears to be part of a denial-of-service attack), then that BPA
then that bundle protocol agent MAY impose a temporary overriding MAY impose a temporary overriding lifetime of shorter duration;
lifetime of shorter duration; such overriding lifetime SHALL NOT such an overriding lifetime SHALL NOT replace the lifetime
replace the lifetime asserted in the bundle but SHALL serve as the asserted in the bundle but SHALL serve as the bundle's effective
bundle's effective lifetime while the bundle resides at that node. lifetime while the bundle resides at that node. Procedures for
Procedures for imposing lifetime overrides are beyond the scope of imposing lifetime overrides are beyond the scope of this
this specification. specification.
For bundles originating at nodes that lack accurate clocks, it is For bundles originating at nodes that lack accurate clocks, it is
recommended that bundle age be obtained from the Bundle Age recommended that bundle age be obtained from the Bundle Age
extension block (see 4.4.2 below) rather than from the difference extension block (see Section 4.4.2) rather than from the
between current time and bundle creation time. Bundle lifetime difference between current time and bundle creation time. Bundle
SHALL be represented as a CBOR unsigned integer item. lifetime SHALL be represented as a CBOR unsigned integer item.
Fragment offset: If and only if the Bundle Processing Control Flags Fragment offset: If and only if the bundle processing control flags
of this Primary block indicate that the bundle is a fragment, of this primary block indicate that the bundle is a fragment,
fragment offset SHALL be present in the primary block. Fragment fragment offset SHALL be present in the primary block. Fragment
offset SHALL be represented as a CBOR unsigned integer indicating offset SHALL be represented as a CBOR unsigned integer indicating
the offset from the start of the original application data unit at the offset from the start of the original ADU at which the bytes
which the bytes comprising the payload of this bundle were located. comprising the payload of this bundle were located.
Total Application Data Unit Length: If and only if the Bundle Total Application Data Unit Length: If and only if the bundle
Processing Control Flags of this Primary block indicate that the processing control flags of this primary block indicate that the
bundle is a fragment, total application data unit length SHALL be bundle is a fragment, total application data unit length SHALL be
present in the primary block. Total application data unit length present in the primary block. Total application data unit length
SHALL be represented as a CBOR unsigned integer indicating the total SHALL be represented as a CBOR unsigned integer indicating the
length of the original application data unit of which this bundle's total length of the original ADU of which this bundle's payload is
payload is a part. a part.
CRC: A CRC SHALL be present in the primary block unless the bundle CRC: A CRC SHALL be present in the primary block unless the bundle
includes a BPsec [BPSEC] Block Integrity Block whose target is the includes a BPSec Block Integrity Block [BPSEC] whose target is the
primary block, in which case a CRC MAY be present in the primary 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 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 the CRC type. The CRC SHALL be computed over the concatenation of
all bytes (including CBOR "break" characters) of the primary block all bytes (including CBOR "break" characters) of the primary block
including the CRC field itself, which for this purpose SHALL be including the CRC field itself, which, for this purpose, SHALL be
temporarily populated with all bytes set to zero. temporarily populated with all bytes set to zero.
4.3.2. Canonical Bundle Block Format 4.3.2. Canonical Bundle Block Format
Every block other than the primary block (all such blocks are termed Every block other than the primary block (all such blocks are termed
"canonical" blocks) SHALL be represented as a CBOR array; the number "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 of elements in the array SHALL be 5 (if CRC type is zero) or 6
(otherwise). (otherwise).
The fields of every canonical block SHALL be as follows, listed in The fields of every canonical block SHALL be as follows, listed in
the order in which they MUST appear: the order in which they MUST appear:
. Block type code, an unsigned integer. Bundle block type code 1 Block type code: An unsigned integer. Bundle block type code 1
indicates that the block is a bundle payload block. Block type indicates that the block is a Bundle Payload Block. Other block
codes 2 through 9 are explicitly reserved as noted later in type codes are described in Section 9.1. Block type codes 192
this specification. Block type codes 192 through 255 are not through 255 are not reserved and are available for private and/or
reserved and are available for private and/or experimental use. experimental use. All other block type code values are reserved
All other block type code values are reserved for future use. for future use.
. Block number, an unsigned integer as discussed in 4.1 above.
Block number SHALL be represented as a CBOR unsigned integer.
. Block processing control flags as discussed in Section 4.2.4
above.
. CRC type as discussed in Section 4.2.1 above.
. 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 Payload Block in
particular (block type 1), the block-type-specific data field,
termed the "payload", SHALL be an application data unit, 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 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 "Extension blocks" are all blocks other than the primary and payload
blocks. Three types of extension blocks are defined below. All blocks. Three types of extension blocks are defined below. All
implementations of the Bundle Protocol specification (the present implementations of the Bundle Protocol specification (the present
document) MUST include procedures for recognizing, parsing, and document) MUST include procedures for recognizing, parsing, and
acting on, but not necessarily producing, these types of extension acting on, but not necessarily producing, these types of extension
blocks. blocks.
The specifications for additional types of extension blocks must The specifications for additional types of extension blocks must
indicate whether or not BP implementations conforming to those indicate whether or not BP implementations conforming to those
specifications must recognize, parse, act on, and/or produce blocks specifications must recognize, parse, act on, and/or produce blocks
of those types. As not all nodes will necessarily instantiate BP of those types. As not all nodes will necessarily instantiate BP
implementations that conform to those additional specifications, it implementations that conform to those additional specifications, it
is possible for a node to receive a bundle that includes extension is possible for a node to receive a bundle that includes extension
blocks that the node cannot process. The values of the block blocks that the node cannot process. The values of the block
processing control flags indicate the action to be taken by the processing control flags indicate the action to be taken by the BPA
bundle protocol agent when this is the case. when this is the case.
No mandated procedure in this specification is unconditionally No mandated procedure in this specification is unconditionally
dependent on the absence or presence of any extension block. dependent on the absence or presence of any extension block.
Therefore any bundle protocol agent MAY insert or remove any Therefore, any BPA MAY insert or remove any extension block in any
extension block in any bundle, subject to all mandates in the Bundle bundle, subject to all mandates in the Bundle Protocol specification
Protocol specification and all extension block specifications to and all extension block specifications to which the node's BP
which the node's BP implementation conforms. Note that removal of implementation conforms. Note that removal of an extension block
an extension block will probably disable one or more elements of will probably disable one or more elements of bundle processing that
bundle processing that were intended by the BPA that inserted that were intended by the BPA that inserted that block. In particular,
block. In particular, note that removal of an extension block that note that removal of an extension block that is one of the targets of
is one of the targets of a BPsec security block may render the a BPSec security block may render the bundle unverifiable.
bundle unverifiable.
The following extension blocks are defined in the current document. The following extension blocks are defined in the current document.
4.4.1. Previous Node 4.4.1. Previous Node
The Previous Node block, block type 6, identifies the node that 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 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 the bundle currently resides); its block-type-specific data is the
node ID of that forwarder node which SHALL take the form of a node node ID of that forwarder node. That node ID SHALL conform to
ID represented as described in Section 4.2.5.2. above. If the local Section 4.2.5.2. If the local node is the source of the bundle, then
node is the source of the bundle, then the bundle MUST NOT contain the bundle MUST NOT contain any Previous Node Block. Otherwise, the
any Previous Node block. Otherwise the bundle SHOULD contain one bundle SHOULD contain one (1) occurrence of this type of block and
(1) occurrence of this type of block and MUST NOT contain more than MUST NOT contain more than one.
one.
4.4.2. Bundle Age 4.4.2. Bundle Age
The Bundle Age block, block type 7, contains the number of The Bundle Age Block, block type 7, contains the number of
milliseconds that have elapsed between the time the bundle was milliseconds that have elapsed between the time the bundle was
created and time at which it was most recently forwarded. It is 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 intended for use by nodes lacking access to an accurate clock, to aid
aid in determining the time at which a bundle's lifetime expires. in determining the time at which a bundle's lifetime expires. The
The block-type-specific data of this block is an unsigned integer block-type-specific data of this block is an unsigned integer
containing the age of the bundle in milliseconds, which SHALL be containing the age of the bundle in milliseconds, which SHALL be
represented as a CBOR unsigned integer item. (The age of the bundle 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 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 forwarding nodes, up to the time at which the bundle was most
recently forwarded, plus the summation of signal propagation time recently forwarded, plus the summation of signal propagation time
over all episodes of transmission between forwarding nodes. over all episodes of transmission between forwarding nodes.
Determination of these values is an implementation matter.) If the Determination of these values is an implementation matter.) If the
bundle's creation time is zero, then the bundle MUST contain exactly bundle's creation time is zero, then the bundle MUST contain exactly
one (1) occurrence of this type of block; otherwise, the bundle MAY 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 contain at most one (1) occurrence of this type of block. A bundle
MUST NOT contain multiple occurrences of the bundle age block, as MUST NOT contain multiple occurrences of the Bundle Age Block, as
this could result in processing anomalies. this could result in processing anomalies.
4.4.3. Hop Count 4.4.3. Hop Count
The Hop Count block, block type 10, contains two unsigned integers, 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 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. Hop 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 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; NOT be changed at any time after creation of the Hop Count Block; the
the hop count value SHOULD initially be zero and SHOULD be increased hop count value SHOULD initially be zero and SHOULD be increased by 1
by 1 on each hop. on each hop.
The hop count block is mainly intended as a safety mechanism, a The Hop Count Block is mainly intended as a safety mechanism, a means
means of identifying bundles for removal from the network that can of identifying bundles for removal from the network that can never be
never be delivered due to a persistent forwarding error. Hop count delivered due to a persistent forwarding error. The hop count is
is particularly valuable as a defense against routing anomalies that particularly valuable as a defense against routing anomalies that
might cause a bundle to be forwarded in a cyclical "ping-pong" might cause a bundle to be forwarded in a cyclical "ping-pong"
fashion between two nodes. When a bundle's hop count exceeds its fashion between two nodes. When a bundle's hop count exceeds its hop
hop limit, the bundle SHOULD be deleted for the reason "hop limit limit, the bundle SHOULD be deleted for the reason "Hop limit
exceeded", following the bundle deletion procedure defined in exceeded", following the Bundle Deletion procedure defined in
Section 5.10. Section 5.10.
Procedures for determining the appropriate hop limit for a bundle Procedures for determining the appropriate hop limit for a bundle are
are beyond the scope of this specification. beyond the scope of this specification.
The block-type-specific data in a hop count block SHALL be The block-type-specific data in a Hop Count Block SHALL be
represented as a CBOR array comprising two items. The first item of 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 this array SHALL be the bundle's hop limit, represented as a CBOR
unsigned integer. The second item of this array SHALL be the unsigned integer. The second item of this array SHALL be the
bundle's hop count, represented as a CBOR unsigned integer. A bundle bundle's hop count, represented as a CBOR unsigned integer. A bundle
MAY contain one occurrence of this type of block but MUST NOT MAY contain one occurrence of this type of block but MUST NOT contain
contain more than one. more than one.
5. Bundle Processing 5. Bundle Processing
The bundle processing procedures mandated in this section and in The bundle-processing procedures mandated in this section and in
Section 6 govern the operation of the Bundle Protocol Agent and the Section 6 govern the operation of the BPA and the application agent
Application Agent administrative element of each bundle node. They administrative element of each bundle node. They are neither
are neither exhaustive nor exclusive. Supplementary DTN protocol exhaustive nor exclusive. Supplementary DTN protocol specifications
specifications (including, but not restricted to, the Bundle (including, but not restricted to, Bundle Protocol Security [BPSEC])
Security Protocol [BPSEC]) may augment, override, or supersede the may augment, override, or supersede the mandates of this document.
mandates of this document.
5.1. Generation of Administrative Records 5.1. Generation of Administrative Records
All transmission of bundles is in response to bundle transmission All transmission of bundles is in response to bundle transmission
requests presented by nodes' application agents. When required to requests presented by nodes' application agents. When required to
"generate" an administrative record (such as a bundle status "generate" an administrative record (such as a bundle status report),
report), the bundle protocol agent itself is responsible for causing the BPA itself is responsible for causing a new bundle to be
a new bundle to be transmitted, conveying that record. In concept, transmitted, conveying that record. In concept, the BPA discharges
the bundle protocol agent discharges this responsibility by this responsibility by directing the administrative element of the
directing the administrative element of the node's application agent node's application agent to construct the record and request its
to construct the record and request its transmission as detailed in transmission as detailed in Section 6. In practice, the manner in
Section 6 below. In practice, the manner in which administrative which administrative record generation is accomplished is an
record generation is accomplished is an implementation matter, implementation matter, provided the constraints noted in Section 6
provided the constraints noted in Section 6 are observed. are observed.
Status reports are relatively small bundles. Moreover, even when Status reports are relatively small bundles. Moreover, even when the
the generation of status reports is enabled the decision on whether generation of status reports is enabled, the decision on whether or
or not to generate a requested status report is left to the not to generate a requested status report is left to the discretion
discretion of the bundle protocol agent. Nonetheless, note that of the BPA. Nonetheless, note that requesting status reports for any
requesting status reports for any single bundle might easily result single bundle might easily result in the generation of (1 + (2
in the generation of (1 + (2 *(N-1))) status report bundles, where N *(N-1))) status report bundles, where N is the number of nodes on the
is the number of nodes on the path from the bundle's source to its path from the bundle's source to its destination, inclusive. That
destination, inclusive. That is, the requesting of status reports is, the requesting of status reports for large numbers of bundles
for large numbers of bundles could result in an unacceptable could result in an unacceptable increase in the bundle traffic in the
increase in the bundle traffic in the network. For this reason, the network. For this reason, the generation of status reports MUST be
generation of status reports MUST be disabled by default and enabled disabled by default and enabled only when the risk of excessive
only when the risk of excessive network traffic is deemed network traffic is deemed acceptable. Mechanisms that could assist
acceptable. Mechanisms that could assist in assessing and in assessing and mitigating this risk, such as pre-placed agreements
mitigating this risk, such as pre-placed agreements authorizing the authorizing the generation of status reports under specified
generation of status reports under specified circumstances, are circumstances, are beyond the scope of this specification.
beyond the scope of this specification.
Notes on administrative record terminology: Notes on administrative record terminology:
. A "bundle reception status report" is a bundle status report * A "bundle reception status report" is a bundle status report with
with the "reporting node received bundle" flag set to 1. 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 * A "bundle forwarding status report" is a bundle status report with
the "Reporting node forwarded the bundle" flag set to 1.
The steps in processing a bundle transmission request are: * A "bundle delivery status report" is a bundle status report with
the "Reporting node delivered the bundle" flag set to 1.
Step 1: Transmission of the bundle is initiated. An outbound bundle * A "bundle deletion status report" is a bundle status report with
MUST be created per the parameters of the bundle transmission the "Reporting node deleted the bundle" flag set to 1.
request, with the retention constraint "Dispatch pending". The
source node ID of the bundle MUST be either the null endpoint ID,
indicating that the source of the bundle is anonymous, or else 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.2. Bundle Transmission
5.3. Bundle Dispatching 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 (Note that this procedure is initiated only following completion of
Step 4 of Section 5.6.) Step 4 of Section 5.6.)
The steps in dispatching a bundle are: The steps in dispatching a bundle are as follows:
Step 1: If the bundle's destination endpoint is an endpoint of which Step 1: If the bundle's destination endpoint is an endpoint of which
the node is a member, the bundle delivery procedure defined in the node is a member, the Bundle Delivery procedure defined
Section 5.7 MUST be followed and for the purposes of all subsequent in Section 5.7 MUST be followed and, for the purposes of all
processing of this bundle at this node the node's membership in the subsequent processing of this bundle at this node, the
bundle's destination endpoint SHALL be disavowed; specifically, even node's membership in the bundle's destination endpoint SHALL
though the node is a member of the bundle's destination endpoint, be disavowed; specifically, even though the node is a member
the node SHALL NOT undertake to forward the bundle to itself in the of the bundle's destination endpoint, the node SHALL NOT
course of performing the procedure described in Section 5.4. undertake to forward the bundle to itself in the course of
performing the procedure described in Section 5.4.
Step 2: Processing proceeds from Step 1 of Section 5.4. Step 2: Processing proceeds from Step 1 of Section 5.4.
5.4. Bundle Forwarding 5.4. Bundle Forwarding
The steps in forwarding a bundle are: The steps in forwarding a bundle are as follows:
Step 1: The retention constraint "Forward pending" MUST be added to Step 1: The retention constraint "Forward pending" MUST be added to
the bundle, and the bundle's "Dispatch pending" retention constraint the bundle, and the bundle's "Dispatch pending" retention
MUST be removed. constraint MUST be removed.
Step 2: The bundle protocol agent MUST determine whether or not Step 2: The BPA MUST determine whether or not forwarding is
forwarding is contraindicated (that is, rendered inadvisable) for contraindicated (that is, rendered inadvisable) for any of
any of the reasons listed in the IANA registry of Bundle Status the reasons listed in the IANA "Bundle Status Report Reason
Report Reason Codes (see section 10.5 below), whose initial contents Codes" registry (see Section 9.5), whose initial contents
are listed in Figure 4. In particular: are listed in Table 1. In particular:
. The bundle protocol agent MAY choose either to forward the * The BPA MAY choose to either forward the bundle directly
bundle directly to its destination node(s) (if possible) or to to its destination node(s) (if possible) or forward the
forward the bundle to some other node(s) for further bundle to some other node(s) for further forwarding. The
forwarding. The manner in which this decision is made may manner in which this decision is made may depend on the
depend on the scheme name in the destination endpoint ID and/or scheme name in the destination endpoint ID and/or on
on other state but in any case is beyond the scope of this other state but in any case is beyond the scope of this
document; one possible mechanism is described in [SABR]. If the document; one possible mechanism is described in [SABR].
BPA elects to forward the bundle to some other node(s) for If the BPA elects to forward the bundle to some other
further forwarding but finds it impossible to select any node(s) for further forwarding but finds it impossible to
node(s) to forward the bundle to, then forwarding is select any node(s) to forward the bundle to, then
contraindicated. forwarding is contraindicated.
. Provided the bundle protocol agent succeeded in selecting the
node(s) to forward the bundle to, the bundle protocol agent
MUST subsequently select the convergence layer adapter(s) whose
services will enable the node to send the bundle to those
nodes. The manner in which specific appropriate convergence
layer adapters are selected is beyond the scope of this
document; the TCP convergence-layer adapter [TCPCL] MUST be
implemented when some or all of the bundles forwarded by the
bundle protocol agent 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 convergence layer adapter(s) to use in forwarding
this bundle, then forwarding is contraindicated.
Step 3: If forwarding of the bundle is determined to be * Provided the BPA succeeded in selecting the node or nodes
contraindicated for any of the reasons listed in the IANA registry to forward the bundle to, the BPA MUST subsequently
of Bundle Status Report Reason Codes (see section 10.5 below), then select the CLA(s) whose services will enable the node to
the Forwarding Contraindicated procedure defined in Section 5.4.1 send the bundle to those nodes. The manner in which
MUST be followed; the remaining steps of Section 5.4 are skipped at specific appropriate CLAs are selected is beyond the
this time. 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 4: For each node selected for forwarding, the bundle protocol Step 3: If forwarding of the bundle is determined to be
agent MUST invoke the services of the selected convergence layer contraindicated for any of the reasons listed in the IANA
adapter(s) in order to effect the sending of the bundle to that "Bundle Status Report Reason Codes" registry (see
node. Determining the time at which the bundle protocol agent Section 9.5), then the Forwarding Contraindicated procedure
invokes convergence layer adapter services is a BPA implementation defined in Section 5.4.1 MUST be followed; the remaining
matter. Determining the time at which each convergence layer steps of this Bundle Forwarding procedure are skipped at
adapter subsequently responds to this service invocation by sending this time.
the bundle is a convergence-layer adapter implementation matter.
Note that:
. If the bundle has a Previous Node block, as defined in 4.4.1 Step 4: For each node selected for forwarding, the BPA MUST invoke
above, then that block MUST be removed from the bundle before the services of the selected CLA(s) in order to effect the
the bundle is forwarded. sending of the bundle to that node. Determining the time at
. If the bundle protocol agent is configured to attach Previous which the BPA invokes CLA services is a BPA implementation
Node blocks to forwarded bundles, then a Previous Node block matter. Determining the time at which each CLA subsequently
containing the node ID of the forwarding node MUST be inserted responds to this service invocation by sending the bundle is
into the bundle before the bundle is forwarded. a CLA implementation matter. Note that:
. If the bundle has a bundle age block, as defined in 4.4.2.
above, 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 convergence layer adapters have informed * If the bundle has a Previous Node Block, as defined in
the bundle protocol agent that they have concluded their data Section 4.4.1, then that block MUST be removed from the
sending procedures with regard to this bundle, processing may depend bundle before the bundle is forwarded.
on the results of those procedures.
If completion of the data sending procedures by all selected * If the BPA is configured to attach Previous Node Blocks
convergence layer adapters has not resulted in successful forwarding to forwarded bundles, then a Previous Node Block
of the bundle (an implementation-specific determination that is containing the node ID of the forwarding node MUST be
beyond the scope of this specification), then the bundle protocol inserted into the bundle before the bundle is forwarded.
agent 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
which 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 * If the bundle has a Bundle Age Block, as defined in
convergence layer adapters HAS resulted in successful forwarding of Section 4.4.2, then at the last possible moment before
the bundle, or if it has not but the bundle protocol agent does not the CLA initiates conveyance of the bundle via the CL
choose to initiate another attempt to forward the bundle, then: 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).
. If the "request reporting of bundle forwarding" flag in the Step 5: When all selected CLAs have informed the BPA that they have
bundle's status report request field is set to 1, and status concluded their data-sending procedures with regard to this
reporting is enabled, then a bundle forwarding status report bundle, processing may depend on the results of those
SHOULD be generated, destined for the bundle's report-to procedures.
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 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.
The steps in responding to contraindication of forwarding are: 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:
Step 1: The bundle protocol agent MUST determine whether or not to * If the "request reporting of bundle forwarding" flag in the
declare failure in forwarding the bundle. Note: this decision is bundle's status report request field is set to 1 and status
likely to be influenced by the reason for which forwarding is reporting is enabled, then a bundle forwarding status report
contraindicated. 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".
Step 2: If forwarding failure is declared, then the Forwarding * If any applicable Bundle Protocol extensions mandate generation of
Failed procedure defined in Section 5.4.2 MUST be followed. status reports upon conclusion of convergence-layer data-sending
procedures, all such status reports SHOULD be generated with
extension-mandated reason codes.
Otherwise, when - at some future time - the forwarding of this * 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 bundle ceases to be contraindicated, processing proceeds from Step 4
of Section 5.4. of Section 5.4.
5.4.2. Forwarding Failed 5.4.2. Forwarding Failed
The steps in responding to a declaration of forwarding failure are: The steps in responding to a declaration of forwarding failure are as
follows:
Step 1: The bundle protocol agent MAY forward the bundle back to the Step 1: The BPA MAY forward the bundle back to the node that sent
node that sent it, as identified by the Previous Node block, if it, as identified by the Previous Node Block, if present.
present. This forwarding, if performed, SHALL be accomplished by This forwarding, if performed, SHALL be accomplished by
performing Step 4 and Step 5 of section 5.4 where the sole node performing Step 4 and Step 5 of Section 5.4 where the sole
selected for forwarding SHALL be the node that sent the bundle. 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 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 the node is a member, then the bundle's "Forward pending"
constraint MUST be removed. Otherwise, the bundle MUST be deleted: retention constraint MUST be removed. Otherwise, the bundle
the bundle deletion procedure defined in Section 5.10 MUST be MUST be deleted: the Bundle Deletion procedure defined in
followed, citing the reason for which forwarding was determined to Section 5.10 MUST be followed, citing the reason for which
be contraindicated. forwarding was determined to be contraindicated.
5.5. Bundle Expiration 5.5. Bundle Expiration
A bundle expires when the bundle's age exceeds its lifetime as A bundle expires when the bundle's age exceeds its lifetime as
specified in the primary bundle block or as overridden by the bundle specified in the primary bundle block or as overridden by the BPA.
protocol agent. Bundle age MAY be determined by subtracting the Bundle age MAY be determined by subtracting the bundle's creation
bundle's creation timestamp time from the current time if (a) that timestamp time from the current time if (a) that timestamp time is
timestamp time is not zero and (b) the local node's clock is known not zero and (b) the local node's clock is known to be accurate;
to be accurate; otherwise bundle age MUST be obtained from the otherwise, bundle age MUST be obtained from the Bundle Age extension
Bundle Age extension block. Bundle expiration MAY occur at any block. Bundle expiration MAY occur at any point in the processing of
point in the processing of a bundle. When a bundle expires, the a bundle. When a bundle expires, the BPA MUST delete the bundle for
bundle protocol agent MUST delete the bundle for the reason the reason "Lifetime expired" (when the expired lifetime is the
"lifetime expired" (when the expired lifetime is the lifetime as lifetime as specified in the primary block) or "Traffic pared" (when
specified in the primary block) or "traffic pared" (when the expired the expired lifetime is a lifetime override as imposed by the BPA):
lifetime is a lifetime override as imposed by the bundle protocol the Bundle Deletion procedure defined in Section 5.10 MUST be
agent): the bundle deletion procedure defined in Section 5.10 MUST followed.
be followed.
5.6. Bundle Reception 5.6. Bundle Reception
The steps in processing a bundle that has been received from another The steps in processing a bundle that has been received from another
node are: node are as follows:
Step 1: The retention constraint "Dispatch pending" MUST be added to Step 1: The retention constraint "Dispatch pending" MUST be added to
the bundle. the bundle.
Step 2: If the "request reporting of bundle reception" flag in the Step 2: If the "request reporting of bundle reception" flag in the
bundle's status report request field is set to 1, and status bundle's status report request field is set to 1 and status
reporting is enabled, then a bundle reception status report with reporting is enabled, then a bundle reception status report
reason code "No additional information" SHOULD be generated, with reason code "No additional information" SHOULD be
destined for the bundle's report-to endpoint ID. generated, destined for the bundle's report-to endpoint ID.
Step 3: CRCs SHOULD be computed for every block of the bundle that 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 has an attached CRC. If any block of the bundle is
according to this specification (including syntactically invalid malformed according to this specification (including
CBOR), or if any block has an attached CRC and the CRC computed for syntactically invalid CBOR), or if any block has an attached
this block upon reception differs from that attached CRC, then the CRC and the CRC computed for this block upon reception
bundle protocol agent MUST delete the bundle for the reason "Block differs from that attached CRC, then the BPA MUST delete the
unintelligible". The bundle deletion procedure defined in Section bundle for the reason "Block unintelligible". The Bundle
5.10 MUST be followed and all remaining steps of the bundle Deletion procedure defined in Section 5.10 MUST be followed,
reception procedure MUST be skipped. 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 Step 4: For each block in the bundle that is an extension block that
the bundle protocol agent cannot process: the BPA cannot process:
. If the block processing flags in that block indicate that a * If the block processing control flags in that block
status report is requested in this event, and status reporting indicate that a status report is requested in this event
is enabled, then a bundle reception status report with reason and if status reporting is enabled, then a bundle
code "Block unsupported" SHOULD be generated, destined for the reception status report with reason code "Block
bundle's report-to endpoint ID. unsupported" SHOULD be generated, destined for the
. If the block processing flags in that block indicate that the bundle's report-to endpoint ID.
bundle must be deleted in this event, then the bundle protocol
agent 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 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 bundle protocol
agent MUST remove this block from the bundle.
. If the block processing flags in that block indicate neither
that the bundle must be deleted nor that that the block must be
discarded, then processing continues with the next extension
block that the bundle protocol agent cannot process, if any;
otherwise, processing proceeds from step 5.
Step 5: Processing proceeds from Step 1 of Section 5.3. * 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.
5.7. Local Bundle Delivery * 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 The steps in processing a bundle that is destined for an endpoint of
which this node is a member are: which this node is a member are as follows:
Step 1: If the received bundle is a fragment, the application data Step 1: If the received bundle is a fragment, the ADU Reassembly
unit reassembly procedure described in Section 5.9 MUST be followed. procedure described in Section 5.9 MUST be followed. If
If this procedure results in reassembly of the entire original this procedure results in reassembly of the entire original
application data unit, processing of the fragmentary bundle whose ADU, processing of the fragmentary bundle whose payload has
payload has been replaced by the reassembled application data unit been replaced by the reassembled ADU (whether this bundle or
(whether this bundle or a previously received fragment) proceeds a previously received fragment) proceeds from Step 2;
from Step 2; otherwise, the retention constraint "Reassembly otherwise, the retention constraint "Reassembly pending"
pending" MUST be added to the bundle and all remaining steps of this MUST be added to the bundle, and all remaining steps of this
procedure MUST be skipped. procedure MUST be skipped.
Step 2: Delivery depends on the state of the registration whose Step 2: Delivery depends on the state of the registration whose
endpoint ID matches that of the destination of the bundle: endpoint ID matches that of the destination of the bundle:
. An additional implementation-specific delivery deferral * An additional implementation-specific delivery deferral
procedure MAY optionally be associated with the registration. procedure MAY optionally be associated with the
. If the registration is in the Active state, then the bundle registration.
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.
Delivery failure action MUST be one of the following:
o defer delivery of the bundle subject to this registration * If the registration is in the Active state, then the
until (a) this bundle is the least recently received of bundle MUST be delivered automatically as soon as it is
all bundles currently deliverable subject to this the next bundle that is due for delivery according to the
registration and (b) either the registration is polled or BPA's bundle delivery scheduling policy (an
else the registration is in the Active state, and also implementation matter).
perform any additional delivery deferral procedure
associated with the registration; or
o abandon delivery of the bundle subject to this registration * If the registration is in the Passive state, or if
(as defined in 3.1. ). 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:
Step 3: As soon as the bundle has been delivered, if the "request - Defer delivery of the bundle subject to this
reporting of bundle delivery" flag in the bundle's status report registration until (a) this bundle is the least
request field is set to 1 and bundle status reporting is enabled, recently received of all bundles currently deliverable
then a bundle delivery status report SHOULD be generated, destined subject to this registration and (b) either the
for the bundle's report-to endpoint ID. Note that this status report registration is polled or the registration is in the
only states that the payload has been delivered to the application Active state, and also perform any additional delivery
agent, not that the application agent has processed that payload. deferral procedure associated with the registration,
or
5.8. Bundle Fragmentation - Abandon delivery of the bundle subject to this
registration (as defined in Section 3.1).
It may at times be advantageous for bundle protocol agents to reduce Step 3: As soon as the bundle has been delivered, if the "request
the sizes of bundles in order to forward them. This might be the reporting of bundle delivery" flag in the bundle's status
case, for example, if a node to which a bundle is to be forwarded is report request field is set to 1 and bundle status reporting
accessible only via intermittent contacts and no upcoming contact is is enabled, then a bundle delivery status report SHOULD be
long enough to enable the forwarding of the entire bundle. generated, destined for the bundle's report-to endpoint ID.
Note that this status report only states that the payload
has been delivered to the application agent, not that the
application agent has processed that payload.
The size of a bundle can be reduced by "fragmenting" the bundle. To 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 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 two "fragments" -- new bundles with the same source node ID and
creation timestamp as the original bundle - whose payloads MUST be creation timestamp as the original bundle -- whose payloads MUST be
the first N and the last (M - N) bytes of the original bundle's the first N and the last (M - N) bytes of the original bundle's
payload, where 0 < N < M. payload, where 0 < N < M.
Note that fragments are bundles and therefore may themselves be Note that fragments are bundles and therefore may themselves be
fragmented, so multiple episodes of fragmentation may in effect fragmented, so multiple episodes of fragmentation may in effect
replace the original bundle with more than two fragments. (However, replace the original bundle with more than two fragments. (However,
there is only one 'level' of fragmentation, as in IP fragmentation.) there is only one "level" of fragmentation, as in IP fragmentation.)
Any bundle whose primary block's bundle processing flags do NOT Any bundle whose primary block's bundle processing control flags do
indicate that it must not be fragmented MAY be fragmented at any *NOT* indicate that it must not be fragmented MAY be fragmented at
time, for any purpose, at the discretion of the bundle protocol any time, for any purpose, at the discretion of the BPA. *NOTE*,
agent. NOTE, however, that some combinations of bundle however, that some combinations of bundle fragmentation, replication,
fragmentation, replication, and routing might result in unexpected and routing might result in unexpected traffic patterns.
traffic patterns.
Fragmentation SHALL be constrained as follows: Fragmentation SHALL be constrained as follows:
. The concatenation of the payloads of all fragments produced by * The concatenation of the payloads of all fragments produced by
fragmentation MUST always be identical to the payload of the fragmentation MUST always be identical to the payload of the
fragmented bundle (that is, the bundle that is being fragmented bundle (that is, the bundle that is being fragmented).
fragmented). Note that the payloads of fragments resulting from Note that the payloads of fragments resulting from different
different fragmentation episodes, in different parts of the fragmentation episodes, in different parts of the network, may be
network, may be overlapping subsets of the fragmented bundle's overlapping subsets of the fragmented bundle's payload.
payload.
. The primary block of each fragment MUST differ from that of the
fragmented bundle, in that the bundle processing 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 * 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.
Note that the bundle fragmentation procedure described in 5.8 above * 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 may result in the replacement of a single original bundle with an
arbitrarily large number of fragmentary bundles. In order to be arbitrarily large number of fragmentary bundles. In order to be
delivered at a destination node, the original bundle's payload must delivered at a destination node, the original bundle's payload must
be reassembled from the payloads of those fragments. be reassembled from the payloads of those fragments.
The "material extents" of a received fragment's payload are all The "material extents" of a received fragment's payload are all
continuous sequences of bytes in that payload that do not overlap continuous sequences of bytes in that payload that do not overlap
with the material extents of the payloads of any previously received with the material extents of the payloads of any previously received
fragments with the same source node ID and creation timestamp. If fragments with the same source node ID and creation timestamp. If
the concatenation - as informed by fragment offsets and payload the concatenation -- as informed by fragment offsets and payload
lengths - of the material extents of the payloads of this fragment lengths -- of the material extents of the payloads of this fragment
and all previously received fragments with the same source node ID and all previously received fragments with the same source node ID
and creation timestamp as this fragment forms a continuous byte and creation timestamp as this fragment forms a continuous byte array
array whose length is equal to the total application data unit whose length is equal to the total application data unit length noted
length noted in the fragment's primary block, then: in the fragment's primary block, then:
. This byte array -- the reassembled application data unit -- * This byte array -- the reassembled ADU -- MUST replace the payload
MUST replace the payload of that fragment whose material of that fragment whose material extents include the extent at
extents include the extent at offset zero. Note that this will offset zero. Note that this will enable delivery of the
enable delivery of the reconstituted original bundle as reconstituted original bundle as described in Step 1 of
described in Step 1 of 5.7. 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 application data units from fragments occurs at * The "Reassembly pending" retention constraint MUST be removed from
the nodes that are members of destination endpoints as necessary; an every other fragment with the same source node ID and creation
application data unit MAY also be reassembled at some other node on timestamp as this fragment.
the path to the destination.
5.10. Bundle Deletion Note: Reassembly of ADUs from fragments occurs at the nodes that are
members of destination endpoints as necessary; an ADU MAY also be
reassembled at some other node on the path to the destination.
The steps in deleting a bundle are: 5.10. Bundle Deletion
Step 1: If the "request reporting of bundle deletion" flag in the The steps in deleting a bundle are as follows:
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. 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.
5.11. Discarding a Bundle Step 2: All of the bundle's retention constraints MUST be removed.
As soon as a bundle has no remaining retention constraints it MAY be 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 discarded, thereby releasing any persistent storage that may have
been allocated to it. been allocated to it.
5.12. Canceling a Transmission 5.12. Canceling a Transmission
When requested to cancel a specified transmission, where the bundle When requested to cancel a specified transmission, where the bundle
created upon initiation of the indicated transmission has not yet created upon initiation of the indicated transmission has not yet
been discarded, the bundle protocol agent MUST delete that bundle been discarded, the BPA MUST delete that bundle for the reason
for the reason "transmission cancelled". For this purpose, the "Transmission canceled". For this purpose, the procedure defined in
procedure defined in Section 5.10 MUST be followed. Section 5.10 MUST be followed.
6. Administrative Record Processing 6. Administrative Record Processing
6.1. Administrative Records 6.1. Administrative Records
Administrative records are standard application data units that are Administrative records are standard ADUs that are used in providing
used in providing some of the features of the Bundle Protocol. One some of the features of the Bundle Protocol. Bundle Protocol
type of administrative record has been defined to date: bundle administrative record types are registered in the IANA "Bundle
status reports. Note that additional types of administrative 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 records may be defined by supplementary DTN protocol specification
documents. documents.
Every administrative record consists of: Every administrative record consists of:
. Record type code (an unsigned integer for which valid values * A record type code (an unsigned integer for which valid values are
are as defined below). as defined below).
. Record content in type-specific format.
Valid administrative record type codes are defined as follows:
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 1 | Bundle status report. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
Figure 3: Administrative Record Type Codes * Record content in type-specific format.
Each BP administrative record SHALL be represented as a CBOR array Each BP administrative record SHALL be represented as a CBOR array
comprising two items. comprising two items.
The first item of the array SHALL be a record type code, which SHALL The first item of the array SHALL be a record type code, which SHALL
be represented as a CBOR unsigned integer. be represented as a CBOR unsigned integer.
The second element of this array SHALL be the applicable CBOR The second element of this array SHALL be the applicable CBOR
representation of the content of the record. Details of the CBOR encoding of the content of the record. Details of the CBOR encoding
representation of administrative record type 1 are provided below. of administrative record type 1 are provided below. Details of the
Details of the CBOR representation of other types of administrative CBOR encoding of other types of administrative records are included
record type are included in the specifications defining those in the specifications defining those records.
records.
6.1.1. Bundle Status Reports 6.1.1. Bundle Status Reports
The transmission of "bundle status reports" under specified The transmission of "bundle status reports" under specified
conditions is an option that can be invoked when transmission of a conditions is an option that can be invoked when transmission of a
bundle is requested. These reports are intended to provide bundle is requested. These reports are intended to provide
information about how bundles are progressing through the system, information about how bundles are progressing through the system,
including notices of receipt, forwarding, final delivery, and including notices of receipt, forwarding, final delivery, and
deletion. They are transmitted to the Report-to endpoints of deletion. They are transmitted to the report-to endpoints of
bundles. bundles.
Each bundle status report SHALL be represented as a CBOR array. The 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 number of elements in the array SHALL be either 6 (if the subject
bundle is a fragment) or 4 (otherwise). bundle is a fragment) or 4 (otherwise).
The first item of the bundle status report array SHALL be bundle The first element of the bundle status report SHALL be bundle status
status information represented as a CBOR array of at least 4 information represented as a CBOR array of at least four elements.
elements. The first four items of the bundle status information The first four elements of the bundle status information shall
array shall provide information on the following four status provide information on the following four status assertions, in this
assertions, in this order: order:
. Reporting node received bundle.
. Reporting node forwarded the bundle.
. Reporting node delivered the bundle.
. Reporting node deleted the bundle.
Each item of the bundle status information array SHALL be a bundle
status item represented as a CBOR array; the number of elements in
each such array SHALL be either 2 (if the value of the first item of
this bundle status item is 1 AND the "Report status time" flag was
set to 1 in the bundle processing flags of the bundle whose status
is being reported) or 1 (otherwise). The first item of the bundle
status item array SHALL be a status indicator, a Boolean value
indicating whether or not the corresponding bundle status is
asserted, represented as a CBOR Boolean value. The second item of
the bundle status item array, if present, SHALL indicate the time
(as reported by the local system clock, 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. above.
The second item of the bundle status report array 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 registry in the Bundle Protocol Namespace (see 10.5
below). The initial contents of that registry are listed in Figure
4 below but the list of status report reason codes provided here is
neither exhaustive nor exclusive; supplementary DTN protocol
specifications (including, but not restricted to, the Bundle
Security Protocol [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. | * Reporting node received bundle.
+---------+--------------------------------------------+ * Reporting node forwarded the bundle.
| 9 | Hop limit exceeded. | * Reporting node delivered the bundle.
+---------+--------------------------------------------+ * Reporting node deleted the bundle.
| 10 | Traffic pared (e.g., status reports). | 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).
| 11 | Block unsupported. | 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.
| (other) | Reserved for future use. | +========+============================================+
+---------+--------------------------------------------+ | 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 |
+--------+--------------------------------------------+
Figure 4: Status Report Reason Codes Table 1: Status Report Reason Codes
The third item of the bundle status report array SHALL be the source The third element of the bundle status report SHALL be the source
node ID identifying the source of the bundle whose status is being node ID identifying the source of the bundle whose status is being
reported, represented as described in Section 4.2.5.1.1. above. reported, represented as described in Section 4.2.5.1.1.
The fourth item of the bundle status report array SHALL be the The fourth element of the bundle status report SHALL be the creation
creation timestamp of the bundle whose status is being reported, timestamp of the bundle whose status is being reported, represented
represented as described in Section 4.2.7. above. as described in Section 4.2.7.
The fifth item of the bundle status report array SHALL be present if The fifth element of the bundle status report SHALL be present if and
and only if the bundle whose status is being reported contained a only if the bundle whose status is being reported contained a
fragment offset. If present, it SHALL be the subject bundle's fragment offset. If present, it SHALL be the subject bundle's
fragment offset represented as a CBOR unsigned integer item. fragment offset represented as a CBOR unsigned integer item.
The sixth item of the bundle status report array SHALL be present if The sixth element of the bundle status report SHALL be present if and
and only if the bundle whose status is being reported contained a only if the bundle whose status is being reported contained a
fragment offset. If present, it SHALL be the length of the subject fragment offset. If present, it SHALL be the length of the subject
bundle's payload represented as a CBOR unsigned integer item. bundle's payload represented as a CBOR unsigned integer item.
Note that the forwarding parameters (such as lifetime, applicable Note that the forwarding parameters (such as lifetime, applicable
security measures, etc.) of the bundle whose status is being security measures, etc.) of the bundle whose status is being reported
reported MAY be reflected in the parameters governing the forwarding MAY be reflected in the parameters governing the forwarding of the
of the bundle that conveys a status report, but this is an bundle that conveys a status report, but this is an implementation
implementation matter. Bundle protocol deployment experience to matter. Bundle Protocol deployment experience to date has not been
date has not been sufficient to suggest any clear guidance on this sufficient to suggest any clear guidance on this topic.
topic.
6.2. Generation of Administrative Records 6.2. Generation of Administrative Records
Whenever the application agent's administrative element is directed Whenever the application agent's administrative element is directed
by the bundle protocol agent to generate an administrative record, by the BPA to generate an administrative record, the following
the following procedure must be followed: 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 bundle protocol
agent.
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 convergence layer protocol adapter provides a
defined minimal set of services to the bundle protocol agent. This
convergence layer service specification enumerates those services.
7.2. Summary of Convergence Layer Services
Each convergence layer protocol adapter is expected to provide the
following services to the bundle protocol agent:
. sending a bundle to a bundle node that is reachable via the
convergence layer protocol;
. notifying the bundle protocol agent of the disposition of its
data sending procedures with regard to a bundle, upon
concluding those procedures;
. delivering to the bundle protocol agent 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, the Bundle
Security Protocol [BPSEC]) may expect convergence layer adapters
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, 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. Implementation Status
[NOTE to the RFC Editor: please remove this section before
publication, as well as the reference to RFC 7942.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in RFC
7942. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.
According to RFC 7942, "this will allow reviewers and working groups Step 1: The administrative record must be constructed. If the
to assign due consideration to documents that have the benefit of administrative record references a bundle and the referenced
running code, which may serve as evidence of valuable bundle is a fragment, the administrative record MUST contain
experimentation and feedback that have made the implemented the fragment offset and fragment length.
protocols more mature. It is up to the individual working groups to
use this information as they see fit".
At the time of this writing, there are six known implementations of Step 2: A request for transmission of a bundle whose payload is this
the current document. administrative record MUST be presented to the BPA.
The first known implementation is microPCN (https://upcn.eu/). 7. Services Required of the Convergence Layer
According to the developers:
The Micro Planetary Communication Network (uPCN) is a free 7.1. The Convergence Layer
software project intended to offer an implementation of Delay-
tolerant Networking protocols for POSIX operating systems (well,
and for Linux) plus for the ARM Cortex STM32F4 microcontroller
series. More precisely it currently provides an implementation of
. the Bundle Protocol (BP, RFC 5050), The successful operation of the end-to-end Bundle Protocol depends on
. version 6 of the Bundle Protocol version 7 specification the operation of underlying protocols at what is termed the
draft, "convergence layer"; these protocols accomplish communication between
. the DTN IP Neighbor Discovery (IPND) protocol, and nodes. A wide variety of protocols may serve this purpose, so long
. a routing approach optimized for message-ferry micro LEO as each CLA provides a defined minimal set of services to the BPA.
satellites. This convergence-layer service specification enumerates those
services.
uPCN is written in C and is built upon the real-time operating 7.2. Summary of Convergence-Layer Services
system FreeRTOS. The source code of uPCN is released under the
"BSD 3-Clause License".
The project depends on an execution environment offering link Each CLA is expected to provide the following services to the BPA:
layer protocols such as AX.25. The source code uses the USB
subsystem to interact with the environment.
The second known implementation is PyDTN, developed by X-works, * sending a bundle to a bundle node that is reachable via the
s.r.o (https://x-works.sk/). The final third of the implementation convergence-layer protocol.
was developed during the IETF 101 Hackathon. According to the
developers, PyDTN implements bundle coding/decoding and neighbor
discovery. PyDTN is written in Python and has been shown to be
interoperable with uPCN.
The third known implementation is "Terra" * notifying the BPA of the disposition of its data-sending
(https://github.com/RightMesh/Terra/), a Java implementation procedures with regard to a bundle, upon concluding those
developed in the context of terrestrial DTN. It includes an procedures.
implementation of a "minimal TCP" convergence layer adapter.
The fourth and fifth known implementations are products of * delivering to the BPA a bundle that was sent by a bundle node via
cooperating groups at two German universities: the convergence-layer protocol.
. An implementation written in Go, licensed under GPLv3, is The convergence-layer service interface specified here is neither
focused on being easily extensible suitable for research. It exhaustive nor exclusive. That is, supplementary DTN protocol
is maintained at the University of Marburg and can be accessed specifications (including, but not restricted to, Bundle Protocol
from https://github.com/dtn7/dtn7-go. Security [BPSEC]) may expect CLAs that serve BP implementations
. An implementation written in Rust, licensed under the conforming to those protocols to provide additional services such as
MIT/Apache license, is intended for environments with limited reporting on the transmission and/or reception progress of individual
resources or demanding safety and/or performance requirements. bundles (at completion and/or incrementally), retransmitting data
It is maintained at the Technical University of Darmstadt and that were lost in transit, discarding bundle-conveying data units
can be accessed at https://github.com/dtn7/dtn7-rs/. that the convergence-layer protocol determines are corrupt or
inauthentic, or reporting on the integrity and/or authenticity of
delivered bundles.
The sixth known implementation is the "bpv7" module in version 4.0.0 In addition, the Bundle Protocol relies on the capabilities of
of the Interplanetary Overlay Network (ION) software maintained at protocols at the convergence layer to minimize congestion in the
the Jet Propulsion Laboratory, California Institute of Technology, store-carry-forward overlay network. The potentially long round-trip
for the U.S. National Aeronautics and Space Administration (NASA). times characterizing delay-tolerant networks are incompatible with
end-to-end, reactive congestion-control mechanisms, so convergence-
layer protocols MUST provide rate limiting or congestion control.
9. Security Considerations 8. Security Considerations
The bundle protocol security architecture and the available security The Bundle Protocol security architecture and the available security
services are specified in an accompanying document, the Bundle services are specified in an accompanying document, the Bundle
Security Protocol (BPsec) specification [BPSEC]. Whenever Bundle Protocol Security (BPSec) specification [BPSEC]. Whenever Bundle
Protocol security services (as opposed to the security services Protocol security services (as opposed to the security services
provided by overlying application protocols or underlying provided by overlying application protocols or underlying
convergence-layer protocols) are required, those services SHALL be convergence-layer protocols) are required, those services SHALL be
provided by BPsec rather than by some other mechanism with the same provided by BPSec rather than by some other mechanism with the same
or similar scope. or similar scope.
A Bundle Protocol Agent (BPA) which sources, cryptographically A Bundle Protocol Agent (BPA) that sources, cryptographically
verifies, and/or accepts a bundle MUST implement support for BPsec. verifies, and/or accepts a bundle MUST implement support for BPSec.
Use of BPsec for a particular Bundle Protocol session is optional. Use of BPSec for any single bundle is optional.
The BPsec extensions to Bundle Protocol enable each block of a The BPSec extensions to the Bundle Protocol enable each block of a
bundle (other than a BPsec extension block) to be individually bundle (other than a BPSec extension block) to be individually
authenticated by a signature block (Block Integrity Block, or BIB) authenticated by a signature block (Block Integrity Block, or BIB)
and also enable each block of a bundle other than the primary block and also enable each block of a bundle other than the primary block
(and the BPsec extension blocks themselves) to be individually (and the BPSec extension blocks themselves) to be individually
encrypted by a Block Confidentiality Block (BCB). encrypted by a Block Confidentiality Block (BCB).
Because the security mechanisms are extension blocks that are Because the security mechanisms are extension blocks that are
themselves inserted into the bundle, the protections they afford themselves inserted into the bundle, the protections they afford
apply while the bundle is at rest, awaiting transmission at the next apply while the bundle is at rest, awaiting transmission at the next
forwarding opportunity, as well as in transit. forwarding opportunity, as well as in transit.
Additionally, convergence-layer protocols that ensure authenticity Additionally, convergence-layer protocols that ensure authenticity of
of communication between adjacent nodes in BP network topology communication between adjacent nodes in a BP network topology SHOULD
SHOULD be used where available, to minimize the ability of be used where available, to minimize the ability of unauthenticated
unauthenticated nodes to introduce inauthentic traffic into the nodes to introduce inauthentic traffic into the network.
network. Convergence-layer protocols that ensure confidentiality of Convergence-layer protocols that ensure confidentiality of
communication between adjacent nodes in BP network topology SHOULD communication between adjacent nodes in a BP network topology SHOULD
also be used where available, to minimize exposure of the bundle's also be used where available, to minimize exposure of the bundle's
primary block and other clear-text blocks, thereby offering some primary block and other cleartext blocks, thereby offering some
defense against traffic analysis. defense against traffic analysis.
In order to provide authenticity and/or confidentiality of In order to provide authenticity and/or confidentiality of
communication between BP nodes, the convergence-layer protocol communication between BP nodes, the convergence-layer protocol
requires as input the name(s) of the expected communication peer(s). requires as input the name or names of the expected communication
These must be supplied by the convergence-layer adapter. Details of peer(s). These must be supplied by the CLA. Details of the means by
the means by which the CLA determines which CL endpoint name(s) must which the CLA determines which CL endpoint name(s) must be provided
be provided to the CL protocol are out of scope for this to the CL protocol are out of scope for this specification. Note,
specification. Note, though, that when the CL endpoint names are a though, that when the CL endpoint names are a function of BP endpoint
function of BP endpoint IDs, the correctness and authenticity of IDs, the correctness and authenticity of that mapping will be vital
that mapping will be vital to the overall security properties that to the overall security properties that the CL provides to the
the CL provides to the system. system.
Note that, while the primary block must remain in the clear for Note that, while the primary block must remain in the clear for
routing purposes, the Bundle Protocol could be protected against routing purposes, the Bundle Protocol could be protected against
traffic analysis to some extent by using bundle-in-bundle traffic analysis to some extent by using bundle-in-bundle
encapsulation [BIBE] to tunnel bundles to a safe forward encapsulation [BIBE] to tunnel bundles to a safe forward distribution
distribution point: the encapsulated bundle could form the payload point: the encapsulated bundle could form the payload of an
of an encapsulating bundle, and that payload block could be encapsulating bundle, and that payload block could be encrypted by a
encrypted by a BCB. BCB.
Note that the generation of bundle status reports is disabled by Note that the generation of bundle status reports is disabled by
default because malicious initiation of bundle status reporting default because malicious initiation of bundle status reporting could
could result in the transmission of extremely large numbers of result in the transmission of extremely large numbers of bundles,
bundles, effecting a denial of service attack. Imposing bundle effecting a denial-of-service attack. Imposing bundle lifetime
lifetime overrides would constitute one defense against such an overrides would constitute one defense against such an attack.
attack.
Note also that the reception of large numbers of fragmentary bundles Note also that the reception of large numbers of fragmentary bundles
with very long lifetimes could constitute a denial of service with very long lifetimes could constitute a denial-of-service attack,
attack, occupying storage while pending reassembly that will never occupying storage while pending reassembly that will never occur.
occur. Imposing bundle lifetime overrides would, again, constitute Imposing bundle lifetime overrides would, again, constitute one
one defense against such an attack. defense against such an attack.
This protocol makes use of absolute timestamps for several purposes. This protocol makes use of absolute timestamps for several purposes.
Provisions are included for nodes without accurate clocks to retain Provisions are included for nodes without accurate clocks to retain
most of the protocol functionality, but nodes that are unaware that most of the protocol functionality, but nodes that are unaware that
their clock is inaccurate may exhibit unexpected behavior. their clock is inaccurate may exhibit unexpected behavior.
10. IANA Considerations 9. IANA Considerations
The Bundle Protocol includes fields requiring registries managed by The Bundle Protocol includes fields requiring registries managed by
IANA. IANA.
10.1. Bundle Block Types 9.1. Bundle Block Types
The current Bundle Block Types registry in the Bundle Protocol
Namespace is augmented by adding a column identifying the version of
the Bundle protocol (Bundle Protocol Version) that applies to the
new values. IANA is requested to add the following values, as
described in section 4.3.1, to the Bundle Block Types registry. The
current values in the Bundle Block Types registry should have the
Bundle Protocol Version set to the value "6", as shown below.
+----------+-------+-----------------------------+---------------+
| Bundle | Value | Description | Reference |
| Protocol | | | |
| Version | | | |
+----------+-------+-----------------------------+---------------+
| none | 0 | Reserved | [RFC6255] |
| 6,7 | 1 | Bundle Payload Block | [RFC5050] |
| | | | RFC-to-be |
| 6 | 2 | Bundle Authentication Block | [RFC6257] |
| 6 | 3 | Payload Integrity Block | [RFC6257] |
| 6 | 4 | Payload Confidentiality | [RFC6257] |
| | | Block | |
| 6 | 5 | Previous-Hop Insertion Block| [RFC6259] |
| 7 | 6 | Previous node (proximate | RFC-to-be |
| | | sender) | |
| 7 | 7 | Bundle age (in milliseconds)| RFC-to-be |
| 6 | 8 | Metadata Extension Block | [RFC6258] |
| 6 | 9 | Extension Security Block | [RFC6257] |
| 7 | 10 | Hop count (#prior xmit | RFC-to-be |
| | | attempts) | |
| 7 | 11-191| Unassigned | |
| 6,7 |192-255| Reserved for Private and/or | [RFC5050], |
| | | Experimental Use | RFC-to-be |
+----------+-------+-----------------------------+---------------+
10.2. Primary Bundle Protocol Version 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.
IANA is requested to add the following value to the Primary Bundle +=================+=========+=========================+===========+
Protocol Version registry in the Bundle Protocol Namespace. | 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
| Value | Description | Reference | 9.2. Primary Bundle Protocol Version
+-------+-------------+---------------+ IANA has added the following value to the "Primary Bundle Protocol
Version" subregistry in the "Bundle Protocol" registry.
| 7 | Assigned | RFC-to-be | +=======+=============+===========+
| Value | Description | Reference |
+=======+=============+===========+
| 7 | Assigned | [RFC9171] |
+-------+-------------+-----------+
+-------+-------------+---------------+ Table 3: "Primary Bundle
Protocol Version" Registry
Values 8-255 (rather than 7-255) are now Unassigned. Values 8-255 (rather than 7-255) are now Unassigned.
10.3. Bundle Processing Control Flags 9.3. Bundle Processing Control Flags
The current Bundle Processing Control Flags registry in the Bundle
Protocol Namespace is augmented by adding a column identifying the
version of the Bundle protocol (Bundle Protocol Version) that
applies to the new values. IANA is requested to add the following
values, as described in section 4.1.3, to the Bundle Processing
Control Flags registry. The current values in the Bundle Processing
Control Flags registry should have the Bundle Protocol Version set
to the value 6 or "6, 7", as shown below.
Bundle Processing Control Flags Registry
+--------------------+----------------------------------+----------+
| Bundle | Bit | Description | Reference|
| Protocol| Position | | |
| Version | (right | | |
| | to left) | | |
+--------------------+----------------------------------+----------+
| 6,7 | 0 | Bundle is a fragment |[RFC5050],|
| | | |RFC-to-be |
| 6,7 | 1 | Application data unit is an |[RFC5050],|
| | | administrative record |RFC-to-be |
| 6,7 | 2 | Bundle must not be fragmented |[RFC5050],|
| | | |RFC-to-be |
| 6 | 3 | Custody transfer is requested |[RFC5050] |
| 6 | 4 | Destination endpoint is singleton|[RFC5050] |
| 6,7 | 5 | Acknowledgement by application |[RFC5050],|
| | | is requested |RFC-to-be |
| 7 | 6 | Status time requested in reports |RFC-to-be |
| 6 | 7 | Class of service, priority |[RFC5050] |
| 6 | 8 | Class of service, priority |[RFC5050] |
| 6 | 9 | Class of service, reserved |[RFC5050] |
| 6 | 10 | Class of service, reserved |[RFC5050] |
| 6 | 11 | Class of service, reserved |[RFC5050] |
| 6 | 12 | Class of service, reserved |[RFC5050] |
| 6 | 13 | Class of service, reserved |[RFC5050] |
| 6,7 | 14 | Request reporting of bundle |[RFC5050],|
| | | reception |RFC-to-be |
| 6 | 15 | Request reporting of custody |[RFC5050] |
| | | acceptance | |
| 6,7 | 16 | Request reporting of bundle |[RFC5050],|
| | | forwarding |RFC-to-be |
| 6,7 | 17 | Request reporting of bundle |[RFC5050],|
| | | delivery |RFC-to-be |
| 6,7 | 18 | Request reporting of bundle |[RFC5050],|
| | | deletion |RFC-to-be |
| 6,7 | 19 | Reserved |[RFC5050],|
| | | |RFC-to-be |
| 6,7 | 20 | Reserved |[RFC5050],|
| | | |RFC-to-be |
| | 21-63 | Unassigned | |
+--------------------+----------------------------------+----------+
10.4. Block Processing Control Flags
The current Block Processing Control Flags registry in the Bundle
Protocol Namespace is augmented by adding a column identifying the
version of the Bundle protocol (Bundle Protocol Version) that
applies to the related BP version. The current values in the Block
Processing Control Flags registry should have the Bundle Protocol
Version set to the value 6 or "6, 7", as shown below.
Block Processing Control Flags Registry
+--------------------+----------------------------------+----------+
| Bundle | Bit | Description | Reference|
| Protocol| Position | | |
| Version | (right | | |
| | to left) | | |
+--------------------+----------------------------------+----------+
| 6,7 | 0 | Block must be replicated in |[RFC5050],|
| | | every fragment |RFC-to-be |
| 6,7 | 1 | Transmit status report if block |[RFC5050],|
| | | can't be processed |RFC-to-be |
| 6,7 | 2 | Delete bundle if block can't be |[RFC5050],|
| | | processed |RFC-to-be |
| 6 | 3 | Last block |[RFC5050] |
| 6,7 | 4 | Discard block if it can't be |[RFC5050],|
| | | processed |RFC-to-be |
| 6 | 5 | Block was forwarded without |[RFC5050] |
| | | being processed | |
| 6 | 6 | Block contains an EID reference |[RFC5050] |
| | | field | |
| | 7-63 | Unassigned | |
+--------------------+----------------------------------+----------+
10.5. Bundle Status Report Reason Codes
The current Bundle Status Report Reason Codes registry in the Bundle
Protocol Namespace is augmented by adding a column identifying the
version of the Bundle protocol (Bundle Protocol Version) that
applies to the new values. IANA is requested to add the following
values, as described in section 6.1.1, to the Bundle Status Report
Reason Codes registry. The current values in the Bundle Status
Report Reason Codes registry should have the Bundle Protocol Version
set to the value 6 or 7 or "6, 7", as shown below.
Bundle Status Report Reason Codes Registry
+--------------------+----------------------------------+----------+
| Bundle | Value | Description | Reference|
| Protocol| | | |
| Version | | | |
| | | | |
+--------------------+----------------------------------+----------+
| 6,7 | 0 | No additional information |[RFC5050],|
| | | |RFC-to-be |
| 6,7 | 1 | Lifetime expired |[RFC5050],|
| | | |RFC-to-be |
| 6,7 | 2 | Forwarded over unidirectional |[RFC5050],|
| | | link |RFC-to-be |
| 6,7 | 3 | Transmission canceled |[RFC5050],|
| | | |RFC-to-be |
| 6,7 | 4 | Depleted storage |[RFC5050],|
| | | |RFC-to-be |
| 6,7 | 5 | Destination endpoint ID |[RFC5050],|
| | | unavailable |RFC-to-be |
| 6,7 | 6 | No known route to destination |[RFC5050],|
| | | from here |RFC-to-be |
| 6,7 | 7 | No timely contact with next node |[RFC5050],|
| | | on route |RFC-to-be |
| 6,7 | 8 | Block unintelligible |[RFC5050],|
| | | |RFC-to-be |
| 7 | 9 | Hop limit exceeded |RFC-to-be |
| 7 | 10 | Traffic pared |RFC-to-be |
| 7 | 11 | Block unsupported |RFC-to-be | 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.
| | 12-254 | Unassigned | | +=================+=================+===================+===========+
| 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 | |
+-----------------+-----------------+-------------------+-----------+
| 6,7 | 255 | Reserved |[RFC6255],| Table 4: "Bundle Processing Control Flags" Registry
| | | |RFC-to-be | 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.
10.6. Bundle Protocol URI scheme types +=================+==============+====================+===========+
| 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 | |
+-----------------+--------------+--------------------+-----------+
The Bundle Protocol has a URI scheme type field - an unsigned Table 5: "Block Processing Control Flags" Registry
integer of indefinite length - for which IANA is requested to create
and maintain a new "Bundle Protocol URI Scheme Type" registry in the
Bundle Protocol Namespace. The "Bundle Protocol URI Scheme Type"
registry governs an unsigned integer namespace. Initial values for
the Bundle Protocol URI Scheme Type registry are given below.
The registration policy for this registry is: Standards Action. The 9.5. Bundle Status Report Reason Codes
allocation should only be granted for a standards-track RFC approved
by the IESG.
The value range is: unsigned integer. 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.
Each assignment consists of a URI scheme type name and its +=================+========+========================+===========+
associated description, a reference to the document that defines the | Bundle Protocol | Value | Description | Reference |
URI scheme, and a reference to the document that defines the use of | Version | | | |
this URI scheme in BP endpoint IDs (including the CBOR +=================+========+========================+===========+
representation of those endpoint IDs in transmitted bundles). | 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] |
+-----------------+--------+------------------------+-----------+
Bundle Protocol URI Scheme Type Registry Table 6: "Bundle Status Report Reason Codes" Registry
+---------+-------------+----------------+------------------+ 9.6. Bundle Protocol URI Scheme Types
| | | BP Utilization | URI Definition | 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.
| Value | Description | Reference | Reference | 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.
| 0 | Reserved | n/a | | 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).
| 1 | dtn | RFC-to-be | RFC-to-be | +===========+==============+================+================+
| 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 | | |
+-----------+--------------+----------------+----------------+
| 2 | ipn | RFC-to-be | [RFC6260], | Table 7: "Bundle Protocol URI Scheme Types" Registry
| | | | RFC-to-be | 9.7. dtn URI Scheme
| 3-254 | Unassigned | n/a | | In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes)
registry, IANA has updated the registration of the URI scheme with
the string "dtn" as the scheme name, as follows:
|255-65535| reserved | n/a | | URI scheme name: "dtn"
| >65535 | open for | n/a | | Status: Permanent
| | private use | n/a | | 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>
10.7. URI scheme "dtn" Change controller: IETF (iesg@ietf.org)
In the Uniform Resource Identifier (URI) Schemes (uri-schemes) Reference: [RFC9171]
registry, IANA is requested to update the registration of the URI
scheme with the string "dtn" as the scheme name, as follows:
URI scheme name: "dtn" 9.8. ipn URI Scheme
Status: permanent In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes)
Applications and/or protocols that use this URI scheme name: the registry, IANA has updated the registration of the URI scheme with
Delay-Tolerant Networking (DTN) Bundle Protocol (BP). the string "ipn" as the scheme name, originally documented in RFC
6260 [RFC6260], as follows.
Contact: URI scheme name: "ipn"
Scott Burleigh Status: Permanent
Jet Propulsion Laboratory, Applications and/or protocols that use this URI scheme name: The
Delay-Tolerant Networking (DTN) Bundle Protocol (BP).
California Institute of Technology Contact: Scott Burleigh <sburleig.sb@gmail.com>
scott.c.burleigh@jpl.nasa.gov Change controller: IETF (iesg@ietf.org)
+1 (800) 393-3353 Reference: [RFC9171]
Change controller: 10. References
IETF, iesg@ietf.org 10.1. Normative References
10.8. URI scheme "ipn" [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>.
In the Uniform Resource Identifier (URI) Schemes (uri-schemes) [CRC16] ITU-T, "X.25: Interface between Data Terminal Equipment
registry, IANA is requested to update the registration of the URI (DTE) and Data Circuit-terminating Equipment (DCE) for
scheme with the string "ipn" as the scheme name, originally terminals operating in the packet mode and connected to
documented in RFC 6260 [RFC6260], as follows. 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/>.
URI scheme name: "ipn" [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>.
Status: permanent [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
Applications and/or protocols that use this URI scheme name: the [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Delay-Tolerant Networking (DTN) Bundle Protocol (BP). Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
Contact: [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>.
Scott Burleigh [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>.
Jet Propulsion Laboratory, [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>.
California Institute of Technology [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>.
scott.c.burleigh@jpl.nasa.gov [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>.
+1 (800) 393-3353 [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>.
Change controller: 10.2. Informative References
IETF, iesg@ietf.org [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>.
11. References [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>.
11.1. Normative References [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>.
[BPSEC] Birrane, E., "Bundle Security Protocol Specification", [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
draft-ietf-dtn-bpsec, January 2020. Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>.
[CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4, [RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol
International Telecommunications Union, October 1996. IANA Registries", RFC 6255, DOI 10.17487/RFC6255, May
2011, <https://www.rfc-editor.org/info/rfc6255>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Bundle Security Protocol Specification", RFC 6257,
DOI 10.17487/RFC6257, May 2011,
<https://www.rfc-editor.org/info/rfc6257>.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC6258] Symington, S., "Delay-Tolerant Networking Metadata
4960, September 2007. Extension Block", RFC 6258, DOI 10.17487/RFC6258, May
2011, <https://www.rfc-editor.org/info/rfc6258>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop
Specifications: ABNF", STD 68, RFC 5234, January 2008. Insertion Block", RFC 6259, DOI 10.17487/RFC6259, May
2011, <https://www.rfc-editor.org/info/rfc6259>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
2119 Key Words", BCP 14, RFC 8174, May 2017. RFC 6260, DOI 10.17487/RFC6260, May 2011,
<https://www.rfc-editor.org/info/rfc6260>.
[RFC8949] Borman, C. and P. Hoffman, "Concise Binary Object [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black,
Representation (CBOR)", RFC 8949, December 2020. "Internet Small Computer System Interface (iSCSI) Protocol
(Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April
2014, <https://www.rfc-editor.org/info/rfc7143>.
[SABR] "Schedule-Aware Bundle Routing", CCSDS Recommended Standard [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
734.3-B-1, Consultative Committee for Space Data Systems, July 2019. Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[TCPCL] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for
Tolerant Networking TCP Convergence Layer Protocol Version 4", Challenged Internets", SIGCOMM 2003,
draft-ietf-dtn-tcpclv4, January 2020. DOI 10.1145/863955.863960, August 2003,
<https://dl.acm.org/doi/10.1145/863955.863960>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Appendix A. Significant Changes from RFC 5050
Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
January 2005.
[URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and This document makes the following significant changes from RFC 5050:
Registration Procedures for URI Schemes", RFC 7595, BCP 35, June
2015.
11.2. Informative References * Clarifies the difference between transmission and forwarding.
[ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC * Migrates custody transfer to the bundle-in-bundle encapsulation
4838, April 2007. specification [BIBE].
[BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", draft-ietf- * Introduces the concept of "node ID" as functionally distinct from
dtn-bibect, August 2019. endpoint ID, while having the same syntax.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource * Restructures primary block, making it immutable. Adds optional
Identifiers (IRIs)", RFC 3987, January 2005. CRC.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol * Adds optional CRCs to non-primary blocks.
Specification", RFC 5050, November 2007.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol * Adds block ID number to canonical block format (to support BPSec).
IANA Registries", RFC 6255, May 2011.
[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, * Adds definition of Bundle Age extension block.
"Bundle Security Protocol Specification", RFC 6257, May 2011.
[RFC6258] Symington, S., "Delay-Tolerant Networking Metadata * Adds definition of Previous Node extension block.
Extension Block", RFC 6258, May 2011.
[RFC6259] Symington, S., "Delay-Tolerant Networking Previous-Hop * Adds definition of Hop Count extension block.
Insertion Block", RFC 6259, May 2011.
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", * Removes Quality of Service markings.
RFC 6260, May 2011.
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, * Changes from Self-Delimiting Numeric Values (SDNVs) to CBOR
"Internet Small Computer System Interface (iSCSI) Protocol encoding.
(Consolidated)", RFC 7143, April 2014.
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for * Adds lifetime overrides.
Challenged Internets", SIGCOMM 2003.
12. Acknowledgments * Clarifies that time values are denominated in milliseconds, not
seconds.
This work is freely adapted from RFC 5050, which was an effort of Appendix B. CDDL Expression
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.
This document was prepared using 2-Word-v2.0.template.dot. 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.
13. Significant Changes from RFC 5050 bpv7_start = bundle / #6.55799(bundle)
Points on which this draft significantly differs from RFC 5050 ; Times before 2000 are invalid
include the following:
. Clarify the difference between transmission and forwarding. dtn-time = uint
. Migrate custody transfer to the bundle-in-bundle encapsulation
specification [BIBE].
. Introduce the concept of "node ID" as functionally distinct
from endpoint ID, while having the same syntax.
. Restructure primary block, making it immutable. Add optional
CRC.
. Add optional CRCs to non-primary blocks.
. Add block ID number to canonical block format (to support
BPsec).
. Add definition of bundle age extension block.
. Add definition of previous node extension block.
. Add definition of hop count extension block.
. Remove Quality of Service markings.
. Change from SDNVs to CBOR representation.
. Add lifetime overrides.
. Time values are denominated in milliseconds, not seconds.
Appendix A. For More Information ; CRC enumerated type
Copyright (c) 2021 IETF Trust and the persons identified as authors crc-type = &(
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without crc-none: 0,
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
Appendix B. CDDL expression crc-16bit: 1,
For informational purposes, Carsten Bormann and Brian Sipos have crc-32bit: 2
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 ; Either 16-bit or 32-bit
dtn-time = uint crc-value = (bstr .size 2) / (bstr .size 4)
; CRC enumerated type creation-timestamp = [
crc-type = &( dtn-time, ; absolute time of creation
crc-none: 0, sequence: uint ; sequence within the time
crc-16bit: 1, ]
crc-32bit: 2 eid = $eid .within eid-structure
) eid-structure = [
; Either 16-bit or 32-bit uri-code: uint,
crc-value = (bstr .size 2) / (bstr .size 4) SSP: any
creation-timestamp = [ ]
dtn-time, ; absolute time of creation $eid /= [
sequence: uint ; sequence within the time uri-code: 1,
] SSP: (tstr / 0)
eid = $eid .within eid-structure
eid-structure = [ ]
uri-code: uint, $eid /= [
SSP: any uri-code: 2,
] SSP: [
$eid /= [ nodenum: uint,
uri-code: 1, servicenum: uint
SSP: (tstr / 0) ]
] ]
$eid /= [ ; The root bundle array
uri-code: 2, bundle = [primary-block, *extension-block, payload-block]
SSP: [ primary-block = [
nodenum: uint, version: 7,
servicenum: uint bundle-control-flags,
] crc-type,
] destination: eid,
; The root bundle array source-node: eid,
bundle = [primary-block, *extension-block, payload-block] report-to: eid,
primary-block = [ creation-timestamp,
version: 7, lifetime: uint,
bundle-control-flags, ? (
crc-type, fragment-offset: uint,
destination: eid,
source-node: eid, total-application-data-length: uint
report-to: eid, ),
creation-timestamp, ? crc-value,
lifetime: uint, ]
? ( bundle-control-flags = uint .bits bundleflagbits
fragment-offset: uint, bundleflagbits = &(
total-application-data-length: uint reserved: 20,
), reserved: 19,
? crc-value, bundle-deletion-status-reports-are-requested: 18,
] bundle-delivery-status-reports-are-requested: 17,
bundle-control-flags = uint .bits bundleflagbits bundle-forwarding-status-reports-are-requested: 16,
bundleflagbits = &( reserved: 15,
reserved: 21, bundle-reception-status-reports-are-requested: 14,
reserved: 20, reserved: 13,
reserved: 19, reserved: 12,
bundle-deletion-status-reports-are-requested: 18, reserved: 11,
bundle-delivery-status-reports-are-requested: 17, reserved: 10,
bundle-forwarding-status-reports-are-requested: 16, reserved: 9,
reserved: 15, reserved: 8,
bundle-reception-status-reports-are-requested: 14, reserved: 7,
reserved: 13, status-time-is-requested-in-all-status-reports: 6,
reserved: 12, user-application-acknowledgement-is-requested: 5,
reserved: 11, reserved: 4,
reserved: 10,
reserved: 9, reserved: 3,
reserved: 8, bundle-must-not-be-fragmented: 2,
reserved: 7, payload-is-an-administrative-record: 1,
status-time-is-requested-in-all-status-reports: 6, bundle-is-a-fragment: 0
user-application-acknowledgement-is-requested: 5, )
reserved: 4, ; Abstract shared structure of all non-primary blocks
reserved: 3, canonical-block-structure = [
bundle-must-not-be-fragmented: 2, block-type-code: uint,
payload-is-an-administrative-record: 1, block-number: uint,
bundle-is-a-fragment: 0 block-control-flags,
) crc-type,
; Abstract shared structure of all non-primary blocks ; Each block type defines the content within the byte string
canonical-block-structure = [ block-type-specific-data,
block-type-code: uint, ? crc-value
block-number: uint, ]
block-control-flags, block-control-flags = uint .bits blockflagbits
crc-type, blockflagbits = &(
; Each block type defines the content within the bytestring reserved: 7,
block-type-specific-data, reserved: 6,
? crc-value reserved: 5,
] block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4,
block-control-flags = uint .bits blockflagbits reserved: 3,
blockflagbits = &(
reserved: 7, bundle-must-be-deleted-if-block-cannot-be-processed: 2,
reserved: 6, status-report-must-be-transmitted-if-block-cannot-be-processed:
1,
reserved: 5, block-must-be-replicated-in-every-fragment: 0
block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4, )
reserved: 3, block-type-specific-data = bstr / #6.24(bstr)
bundle-must-be-deleted-if-block-cannot-be-processed: 2, ; Actual CBOR data embedded in a byte string, with optional tag to
indicate so.
status-report-must-be-transmitted-if-block-cannot-be-processed: 1, ; Additional plain bstr allows ciphertext data.
block-must-be-replicated-in-every-fragment: 0 embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) /
bstr
) ; Extension block type, which does not specialize other than the
code/number
block-type-specific-data = bstr / #6.24(bstr) extension-block =
$extension-block .within canonical-block-structure
; Actual CBOR data embedded in a bytestring, with optional tag to ; Generic shared structure of all non-primary blocks
indicate so.
; Additional plain bstr allows ciphertext data. extension-block-use<CodeValue, BlockData> = [
embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) / block-type-code: CodeValue,
bstr
; Extension block type, which does not specialize other than the block-number: (uint .gt 1),
code/number
extension-block = $extension-block .within canonical-block-structure block-control-flags,
; Generic shared structure of all non-primary blocks crc-type,
extension-block-use<CodeValue, BlockData> = [ BlockData,
block-type-code: CodeValue, ? crc-value
block-number: (uint .gt 1), ]
block-control-flags, ; Payload block type
crc-type,
BlockData, payload-block = payload-block-structure .within canonical-block-
structure
? crc-value payload-block-structure = [
] block-type-code: 1,
; Payload block type block-number: 1,
payload-block = payload-block-structure .within canonical-block- block-control-flags,
structure
payload-block-structure = [ crc-type,
block-type-code: 1, $payload-block-data,
block-number: 1, ? crc-value
block-control-flags, ]
crc-type, ; Arbitrary payload data, including non-CBOR byte string
$payload-block-data, $payload-block-data /= block-type-specific-data
? crc-value ; Administrative record as a payload data specialization
] $payload-block-data /= embedded-cbor<admin-record>
; Arbitrary payload data, including non-CBOR bytestring admin-record = $admin-record .within admin-record-structure
$payload-block-data /= block-type-specific-data admin-record-structure = [
; Administrative record as a payload data specialization record-type-code: uint,
$payload-block-data /= embedded-cbor<admin-record> record-content: any
admin-record = $admin-record .within admin-record-structure ]
admin-record-structure = [ ; Only one defined record type
record-type-code: uint,
record-content: any $admin-record /= [1, status-record-content]
] status-record-content = [
; Only one defined record type bundle-status-information,
$admin-record /= [1, status-record-content] status-report-reason-code: uint,
status-record-content = [ source-node-eid: eid,
bundle-status-information, subject-creation-timestamp: creation-timestamp,
status-report-reason-code: uint, ? (
source-node-eid: eid, subject-payload-offset: uint,
subject-creation-timestamp: creation-timestamp, subject-payload-length: uint
? ( )
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,
bundle-status-information = [ reporting-node-delivered-bundle: status-info-content,
reporting-node-received-bundle: status-info-content, reporting-node-deleted-bundle: status-info-content
reporting-node-forwarded-bundle: status-info-content, ]
reporting-node-delivered-bundle: status-info-content, status-info-content = [
reporting-node-deleted-bundle: status-info-content status-indicator: bool,
] ? timestamp: dtn-time
status-info-content = [ ]
status-indicator: bool, ; Previous Node extension block
? timestamp: dtn-time $extension-block /=
] extension-block-use<6, embedded-cbor<ext-data-previous-node>>
; Previous Node extension block ext-data-previous-node = eid
$extension-block /= ; Bundle Age extension block
extension-block-use<6, embedded-cbor<ext-data-previous-node>> $extension-block /=
ext-data-previous-node = eid extension-block-use<7, embedded-cbor<ext-data-bundle-age>>
; Bundle Age extension block ext-data-bundle-age = uint
$extension-block /= ; Hop Count extension block
extension-block-use<7, embedded-cbor<ext-data-bundle-age>> $extension-block /=
ext-data-bundle-age = uint extension-block-use<10, embedded-cbor<ext-data-hop-count>>
; Hop Count extension block ext-data-hop-count = [
$extension-block /= hop-limit: uint,
extension-block-use<10, embedded-cbor<ext-data-hop-count>> hop-count: uint
ext-data-hop-count = [ ]
hop-limit: uint, Acknowledgments
hop-count: uint This work is freely adapted from RFC 5050, which was an effort of the
Delay-Tolerant Networking Research Group. The following DTNRG
participants contributed significant technical material and/or inputs
to that document: Dr. Vinton Cerf of Google; Scott Burleigh, Adrian
Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory; Michael
Demmer of the University of California at Berkeley; Robert Durst,
Keith Scott, and Susan Symington of The MITRE Corporation; Kevin Fall
of Carnegie Mellon University; Stephen Farrell of Trinity College
Dublin; Howard Weiss and Peter Lovell of SPARTA, Inc.; and Manikantan
Ramadas of Ohio University.
] Scott Burleigh would like to thank the Jet Propulsion Laboratory,
California Institute of Technology, for its generous and sustained
support of this work.
Authors' Addresses Authors' Addresses
Scott Burleigh Scott Burleigh
Jet Propulsion Laboratory, California Institute of Technology IPNGROUP
4800 Oak Grove Dr. 1435 Woodhurst Blvd.
Pasadena, CA 91109-8099 McLean, VA 22102
US United States of America
Phone: +1 818 393 3353
Email: Scott.C.Burleigh@jpl.nasa.gov Email: sburleig.sb@gmail.com
Kevin Fall Kevin Fall
Roland Computing Services Roland Computing Services
3871 Piedmont Ave. Suite 8 3871 Piedmont Ave. Suite 8
Oakland, CA 94611 Oakland, CA 94611
US United States of America
Email: kfall+rcs@kfall.com Email: kfall+rcs@kfall.com
Edward J. Birrane Edward J. Birrane, III
Johns Hopkins University Applied Physics Laboratory Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd 11100 Johns Hopkins Rd
Laurel, MD 20723 Laurel, MD 20723
US United States of America
Phone: +1 443 778 7423 Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
 End of changes. 579 change blocks. 
2064 lines changed or deleted 1996 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/