rfc9171xml2.original.xml   rfc9171.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- <!ENTITY I-D.ietf-dtn-bpsec SYSTEM "https://xml2rfc.ietf.org/public/rfc/bib
xml3/reference.I-D.draft-ietf-dtn-bpsec.xml"> -->
<!ENTITY I-D.ietf-dtn-bpsec SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3/
reference.I-D.ietf-dtn-bpsec.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC4960 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4960.xml">
<!ENTITY RFC5234 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5234.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8949 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8949.xml">
<!-- <!ENTITY I-D.ietf-dtn-tcpclv4 SYSTEM "https://xml2rfc.ietf.org/public/rfc/b
ibxml3/reference.I-D.draft-ietf-dtn-tcpclv4.xml"> -->
<!ENTITY I-D.ietf-dtn-tcpclv4 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml
3/reference.I-D.ietf-dtn-tcpclv4.xml">
<!ENTITY RFC3986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3986.xml">
<!ENTITY RFC7595 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7595.xml">
<!-- <!ENTITY I-D.ietf-dtn-bibect SYSTEM "https://xml2rfc.ietf.org/public/rfc/bi
bxml3/reference.I-D.draft-ietf-dtn-bibect.xml"> -->
<!ENTITY I-D.ietf-dtn-bibect SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml3
/reference.I-D.ietf-dtn-bibect.xml">
<!ENTITY RFC3987 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3987.xml">
<!ENTITY RFC5050 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5050.xml">
<!ENTITY RFC6255 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6255.xml">
<!ENTITY RFC6257 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6257.xml">
<!ENTITY RFC6258 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6258.xml">
<!ENTITY RFC6259 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6259.xml">
<!ENTITY RFC6260 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6260.xml">
<!ENTITY RFC7143 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7143.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-dtn-bpbis-31" category="std" ipr=
"trust200902">
<!-- Generated by id2xml 1.5.0 on 2021-04-05T23:37:33Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc text-list-symbols="*o+-"?>
<?rfc toc="yes"?>
<?rfc tocDepth="5"?>
<front>
<title>Bundle Protocol Version 7</title>
<author initials="S." surname="Burleigh" fullname="Scott Burleigh">
<organization abbrev="JPL, Calif. Inst. Of Technology">Jet Propulsion Lab
oratory, California Institute of Technology</organization>
<address><postal><street>4800 Oak Grove Dr.</street>
<city>Pasadena</city><region>CA</region><code>91109-8099</code>
<country>United States of America</country>
</postal>
<phone>+1 818 393 3353</phone>
<email>Scott.C.Burleigh@jpl.nasa.gov</email>
</address>
</author>
<author initials="K." surname="Fall" fullname="Kevin Fall">
<organization>Roland Computing Services</organization>
<address><postal><street>3871 Piedmont Ave. Suite 8</street>
<city>Oakland</city><region>CA</region><code>94611</code>
<country>United States of America</country>
</postal>
<email>kfall+rcs@kfall.com</email>
</address>
</author>
<author initials="E." surname="Birrane" fullname="Edward J. Birrane"> <!-- [CS] updated by Chris 04/13/21 -->
<organization abbrev="APL, Johns Hopkins University">Johns Hopkins Univer
sity Applied Physics Laboratory</organization>
<address><postal><street>11100 Johns Hopkins Rd</street>
<city>Laurel</city><region>MD</region><code>20723</code>
<country>United States of America</country>
</postal>
<phone>+1 443 778 7423</phone>
<email>Edward.Birrane@jhuapl.edu
<!-- draft-ietf-dtn-bpbis-31-manual.txt(3160): Warning: This author is listed in <!DOCTYPE rfc [
the <!ENTITY nbsp "&#160;">
Authors' Addresses section, but was not found on the first page: US <!ENTITY zwsp "&#8203;">
--></email> <!ENTITY nbhy "&#8209;">
</address> <!ENTITY wj "&#8288;">
</author> ]>
<date year="2021" month="April"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dtn-bpbis-31
<workgroup>Networking Working Group</workgroup> " number="9171"
submissionType="IETF" category="std" consensus="true" ipr="trust200902" obsolete
s="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" t
ocDepth="5" version="3">
<!-- [rfced] Please insert any keywords (beyond those that appear in <!-- xml2rfc v2v3 conversion 3.7.0 -->
the title) for use on https://www.rfc-editor.org/search. --> <!-- Generated by id2xml 1.5.0 on 2021-04-05T23:37:33Z -->
<front>
<title>Bundle Protocol Version 7</title>
<seriesInfo name="RFC" value="9171"/>
<author initials="S." surname="Burleigh" fullname="Scott Burleigh">
<organization>IPNGROUP</organization>
<address>
<postal>
<street>1435 Woodhurst Blvd.</street>
<city>McLean</city>
<region>VA</region>
<code>22102</code>
<country>United States of America</country>
</postal>
<email>sburleig.sb@gmail.com</email>
</address>
</author>
<author initials="K." surname="Fall" fullname="Kevin Fall">
<organization>Roland Computing Services</organization>
<address>
<postal>
<street>3871 Piedmont Ave. Suite 8</street>
<city>Oakland</city>
<region>CA</region>
<code>94611</code>
<country>United States of America</country>
</postal>
<email>kfall+rcs@kfall.com</email>
</address>
</author>
<author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, II
I">
<organization abbrev="APL, Johns Hopkins University">Johns Hopkins Univers
ity Applied Physics Laboratory</organization>
<address>
<postal>
<street>11100 Johns Hopkins Rd</street>
<city>Laurel</city>
<region>MD</region>
<code>20723</code>
<country>United States of America</country>
</postal>
<phone>+1 443 778 7423</phone>
<email>Edward.Birrane@jhuapl.edu
</email>
</address>
</author>
<date year="2022" month="January"/>
<workgroup>Networking Working Group</workgroup>
<keyword>example</keyword> <keyword>Delay-tolerant networking</keyword>
<keyword>disruption-tolerant networking</keyword>
<abstract><t> <abstract>
This Internet Draft presents a specification for the Bundle <t>
This document presents a specification for the Bundle
Protocol, adapted from the experimental Bundle Protocol Protocol, adapted from the experimental Bundle Protocol
specification developed by the Delay-Tolerant Networking Research specification developed by the Delay-Tolerant Networking Research
group of the Internet Research Task Force and documented in RFC Group of the Internet Research Task Force and documented in RFC
5050.</t> 5050.
</abstract>
</front>
<middle> </t>
<section title="Introduction" anchor="sect-1"><t> </abstract>
Since the publication of the Bundle Protocol Specification </front>
(Experimental RFC 5050 <xref target="RFC5050"/>) in 2007, the Delay-Tolerant <middle>
Networking (DTN) Bundle Protocol has been implemented in multiple <section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>
Since the publication of the Bundle Protocol specification
(Experimental RFC 5050 <xref target="RFC5050" format="default"/>) in 2007, th
e Delay-Tolerant
Networking (DTN) Bundle Protocol (BP) has been implemented in multiple
programming languages and deployed to a wide variety of computing programming languages and deployed to a wide variety of computing
platforms. This implementation and deployment experience has platforms. This implementation and deployment experience has
identified opportunities for making the protocol simpler, more 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 lessons learned. Significant changes from the Bundle reflecting lessons learned. Significant changes from the Bundle
Protocol specification defined in RFC 5050 are listed in section 13.</t> Protocol specification defined in RFC 5050 are listed in <xref target="app-a"
/>.</t>
<t> <t>
This document describes version 7 of BP.</t> This document describes BP version 7 (BPv7).</t>
<t>
<t> 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. To provide its services, BP may be viewed as sitting at the rates. 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:
<list style="symbols"> </t>
<ul spacing="normal">
<t>Ability to use physical motility for the movement of data</t> <li>Ability to use physical motility for the movement of data.</li>
<li>Ability to move the responsibility for error control from one
<t>Ability to move the responsibility for error control from one node to another.</li>
node to another</t> <li>Ability to cope with intermittent connectivity, including cases
where the sender and receiver are not concurrently present in
<t>Ability to cope with intermittent connectivity, including cases the network.</li>
where the sender and receiver are not concurrently present in <li>Ability to take advantage of scheduled, predicted, and
the network</t> opportunistic connectivity, whether bidirectional or
unidirectional, in addition to continuous connectivity.</li>
<t>Ability to take advantage of scheduled, predicted, and <li>Late binding of overlay-network endpoint identifiers to
opportunistic connectivity, whether bidirectional or underlying constituent network addresses.</li>
unidirectional, in addition to continuous connectivity</t> </ul>
<t>
<t>Late binding of overlay network endpoint identifiers to
underlying constituent network addresses</t>
</list>
</t>
<t>
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].</t> architecture, see <xref target="RFC4838"/> and <xref target="SIGC"/>.</t>
<t>
<t> BP's location within the standard protocol stack is as shown in <xref target=
BP's location within the standard protocol stack is as shown in Figure 1. "fig-1"/>.
BP uses underlying "native" transport and/or network protocols for BP uses underlying "integrated" transport and/or network protocols for
communications within a given constituent network. The layer at which communications within a given constituent network. The layer at which
those underlying protocols are located is here termed the "convergence those underlying protocols are located is here termed the "convergence
layer" and the interface between the bundle protocol and a specific layer", and the interface between the Bundle Protocol and a specific
underlying protocol is termed a "convergence layer adapter".</t> underlying protocol is termed a "convergence-layer adapter".</t>
<t>
<t> <xref target="fig-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).</t> (denoted T1/N1, T2/N2, and T3/N3).</t>
<figure anchor="fig-1">
<figure title="The Bundle Protocol in the Protocol Stack Model" anchor="f <name>The Bundle Protocol in the Protocol Stack Model</name>
ig-1"><artwork><![CDATA[ <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+-----------+ +-----------+ +-----------+ +-----------+
| 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-+ +-^---------+
| T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 | | T1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ T3 |
+---------v-+ +-^---------v-+ +-^---------v + +-^---------+ +---------v-+ +-^---------v-+ +-^---------v + +-^---------+
| 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 ---->|
| | | | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>
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.</t> communications.</t>
<t>
<t>
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:
<list style="symbols"> </t>
<ul spacing="normal">
<t>Operations in the convergence layer adapters that bundle nodes use <li>Operations in the convergence-layer adapters that bundle nodes use
to transport data through specific types of internets. (However, the to transport data through specific types of internets. (However, the
document does discuss the services that must be provided by each document does discuss the services that must be provided by each
adapter at the convergence layer.)</t> adapter at the convergence layer.)</li>
<li>The bundle route computation algorithm.</li>
<t>The bundle route computation algorithm.</t> <li>Mechanisms for populating the routing or forwarding information
bases of bundle nodes.</li>
<t>Mechanisms for populating the routing or forwarding information <li>The mechanisms for securing bundles en route.</li>
bases of bundle nodes.</t> <li> The mechanisms for managing bundle nodes.</li>
</ul>
<t>The mechanisms for securing bundles en route.</t> <t>
<t> The mechanisms for managing bundle nodes.</t>
</list></t>
<t>
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.</t> document will not be interoperable with implementations of RFC 5050.</t>
</section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
<section anchor="sect-3" numbered="true" toc="default">
<name>Service Description</name>
<section anchor="sect-3.1" numbered="true" toc="default">
<name>Definitions</name>
</section> <dl>
<dt>Bundle:</dt>
<section title="Conventions used in this document" anchor="sect-2"><t> <dd>A bundle is a PDU of BP, so named because
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section>
<section title="Service Description" anchor="sect-3"><section title="Defi
nitions" anchor="sect-3.1"><t>
Bundle - A bundle is a protocol data unit of BP, so named because
negotiation of the parameters of a data exchange may be impractical negotiation of the parameters of a data exchange may be impractical
in a delay-tolerant network: it is often better practice to "bundle" in a delay-tolerant network: it is often better practice to "bundle"
with a unit of application data all metadata that might be needed in with a 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.</t> "blocks" of protocol data, which serve various purposes.</dd>
<t> <dt>Block:</dt>
Block - A bundle protocol block is one of the protocol data <dd>A Bundle Protocol block is one of the protocol data
structures that together constitute a well-formed bundle.</t> structures that together constitute a well-formed bundle.</dd>
<t> <dt>Application Data Unit:</dt>
Application Data Unit (ADU) - An application data unit is the unit <dd>An application data unit (ADU) is the unit
of data whose conveyance to the bundle's destination is the purpose of 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).</t> defined below).</dd>
<t> <dt>Bundle payload:</dt>
Bundle payload - A bundle payload (or simply "payload") is the <dd>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 content",
"bundle payload", and "payload" are used interchangeably in this "bundle payload", and "payload" are used interchangeably in this
document. For a bundle that is not a fragment (as defined below), document. For a bundle that is not a fragment (as defined below),
the payload is an application data unit.</t> the payload is an ADU.</dd>
<t> <dt>Partial payload:</dt>
Partial payload - A partial payload is a payload that comprises <dd>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 &lt; N &lt; M. Note that every partial payload is a payload and therefore can be further subdivided into partial payloads.</t> of length M, such that 0 &lt; N &lt; M. Note that every partial payload is a payload and therefore can be further subdivided into partial payloads.</dd>
<t> <dt>Fragment:</dt>
Fragment - A fragment, a.k.a. "fragmentary bundle", is a bundle <dd>A fragment, a.k.a. "fragmentary bundle", is a bundle
whose payload block contains a partial payload.</t> whose payload block contains a partial payload.</dd>
<t> <dt>Bundle node:</dt>
Bundle node - A bundle node (or, in the context of this document, <dd>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 bundles.
Each bundle node has three conceptual components, defined below, as Each bundle node has three conceptual components, defined below, as
shown in Figure 2: a "bundle protocol agent", a set of zero or more shown in <xref target="fig-2"/>: a "Bundle Protocol Agent", a set of zero or
"convergence layer adapters", and an "application agent". ("CL1 PDUs" are the more
PDUs of the convergence-layer protocol used in network "convergence-layer adapters", and an "application agent".
1.)</t> ("CL1 PDUs" are the PDUs of the convergence-layer protocol used in network 1.)<
/dd>
</dl>
<figure title="Components of a Bundle Node" anchor="fig-2"><artwork><![CD <figure anchor="fig-2">
ATA[ <name>Components of a Bundle Node</name>
<artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+-----------------------------------------------------------+ +-----------------------------------------------------------+
|Node | |Node |
| | | |
| +-------------------------------------------------------+ | | +-------------------------------------------------------+ |
| |Application Agent | | | |Application Agent | |
| | | | | | | |
| | +--------------------------+ +----------------------+ | | | | +--------------------------+ +----------------------+ | |
| | |Administrative element | |Application-specific | | | | | |Administrative element | |Application-specific | | |
| | | | |element | | | | | | | |element | | |
| | | | | | | | | | | | | | | |
skipping to change at line 294 skipping to change at line 276
| |CLA 1 | |CLA 2 | |CLA n | | | |CLA 1 | |CLA 2 | |CLA n | |
| | | | | . . . | | | | | | | | . . . | | |
| | | | | | | | | | | | | | | |
+-+------------+-----+------------+-----------+-----------+-+ +-+------------+-----+------------+-----------+-----------+-+
^ ^ ^ ^ ^ ^
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
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <dl>
Bundle protocol agent - The bundle protocol agent (BPA) of a node is <dt>Bundle Protocol Agent:</dt>
<dd>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.</t> procedures of the Bundle Protocol.</dd>
<dt>Convergence-layer adapter:</dt>
<t> <dd>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 BPA,
utilizing the services of some 'native' protocol stack that is utilizing the services of some "integrated" protocol stack that is
supported in one of the networks within which the node is supported in one of the networks within which the node is
functionally located.</t> functionally located.</dd>
<dt>Application agent:</dt>
<t> <dd>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 for
some user purpose. The application agent in turn has two elements, some user purpose. The application agent in turn has two elements:
an administrative element and an application-specific element.</t> an administrative element and an application-specific element.</dd>
<dt>Application-specific element:</dt>
<t> <dd>The application-specific element of
Application-specific element - The application-specific element of
an AA is the node component that constructs, requests transmission an 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.</t> data.</dd>
<dt>Administrative element:</dt>
<t> <dd>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.</t> that the node receives.</dd>
<dt>Administrative record:</dt>
<t> <dd>A BP administrative record is an ADU that is exchanged between the admini
Administrative record - A BP administrative record is an application strative elements of
data unit that is exchanged between the administrative elements of
nodes' application agents for some BP administrative purpose. The nodes' application agents for some BP administrative purpose. The
only administrative record defined in this specification is the only administrative record defined in this specification is the
status report, discussed later.</t> status report, discussed later.</dd>
<dt>Bundle endpoint:</dt>
<t> <dd>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.</t> described in detail in <xref target="sect-4.2.5.1"/>.</dd>
<dt>Singleton endpoint:</dt>
<t> <dd>A singleton endpoint is an endpoint that always
Singleton endpoint - A singleton endpoint is an endpoint that always contains exactly one member.</dd>
contains exactly one member.</t> <dt>Registration:</dt>
<dd>A registration is the state machine characterizing a
<t>
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.</t> information about registrations.</dd>
<dt>Delivery:</dt>
<t> <dd>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 ADU that
subject to a registration as soon as the application data unit that
is the payload of the bundle, together with any relevant metadata is the payload of the bundle, together with any relevant metadata
(an implementation matter), has been presented to the node's (an 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.</t> registration.</dd>
<dt>Deliverability:</dt>
<t> <dd>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 is
the endpoint with which the registration is associated, (b) the 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, and
(c) the bundle has not yet been "abandoned" (as defined below) (c) the bundle has not yet been "abandoned" (as defined below)
subject to this registration.</t> subject to this registration.</dd>
<dt>Abandonment:</dt>
<t> <dd>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.</t> registration.</dd>
<dt>Delivery failure action:</dt>
<t> <dd>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 is
"deliverable" subject to that registration is received at a time "deliverable" subject to that registration is received at a time
when the registration is in the Passive state.</t> when the registration is in the Passive state.</dd>
<dt>Destination:</dt>
<t> <dd>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).</t> above).</dd>
<dt>Transmission:</dt>
<t> <dd>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 that
are members of some endpoint (the bundle's destination) in response are members of some endpoint (the bundle's destination) in response
to a transmission request issued by the node's application agent.</t> to a transmission request issued by the node's application agent.</dd>
<dt>Forwarding:</dt>
<t> <dd>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.</t> bundle to be received by that node.</dd>
<dt>Discarding:</dt>
<t> <dd>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.</t> matter.</dd>
<dt>Retention constraint:</dt>
<t> <dd>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.</t> constraints.</dd>
<dt>Deletion:</dt>
<t> <dd>To delete a bundle is to remove unconditionally all of
Deletion - To delete a bundle is to remove unconditionally all of
the bundle's retention constraints, enabling the bundle to be the bundle's retention constraints, enabling the bundle to be
discarded.</t> discarded.</dd>
</dl>
</section> </section>
<section anchor="sect-3.2" numbered="true" toc="default">
<section title="Discussion of BP concepts" anchor="sect-3.2"><t> <name>Discussion of BP Concepts</name>
<t>
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.</t> that node's local memory, of some bundle that is in the network.</t>
<t>
<t>
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 parameter to that request. The payload for a bundle provided as a parameter to that request. The payload for a bundle
forwarded in response to reception of a bundle is the payload of the forwarded in response to reception of a bundle is the payload of the
received bundle.</t> received bundle.</t>
<t>
<t>
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.</t> special-purpose hardware device, etc.</t>
<t>
<t>
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.</t> implemented in hardware.</t>
<t>
<t>
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 integrated
protocol, or it may offer additional CL-specific functionality. The protocol, or it may offer additional CL-specific functionality. The
manner in which a CLA sends and receives bundles, as well as the manner in which a CLA sends and receives bundles, as well as the
definitions of CLAs and CL protocols, are beyond the scope of this definitions of CLAs and CL protocols, are beyond the scope of this
specification.</t> specification.</t>
<t>
<t>
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 bundles may be "tunneled" through encapsulating That is, outgoing bundles may be "tunneled" through encapsulating
bundles: bundles:
<list style="symbols"> </t>
<ul spacing="normal">
<t>An outgoing bundle constitutes a byte array. This byte array may, <li>An outgoing bundle constitutes a byte array. This byte array may,
like any other, be presented to the bundle protocol agent as an like any other, be presented to the BPA as an
application data unit that is to be transmitted to some endpoint.</t> ADU that is to be transmitted to some endpoint.</li>
<li>The original bundle thus forms the payload of an encapsulating
<t>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).</li>
protocol(s).</t> <li>When the encapsulating bundle is received, its payload is
delivered to the peer application agent administrative element,
<t>When the encapsulating bundle is received, its payload is which then instructs the BPA to dispatch that
delivered to the peer application agent administrative element, original bundle in the usual way.</li>
which then instructs the bundle protocol agent to dispatch that </ul>
original bundle in the usual way.</t> <t>
</list>
</t>
<t>
The purposes for which this technique may be useful (such as cross-domain The purposes for which this technique may be useful (such as cross-domain
security) are beyond the scope of this specification.</t> security) are beyond the scope of this specification.</t>
<t>
<t>
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 element of the AA to direct each other to take action administrative element of the AA to direct each other to take action
under specific circumstances.</t> under specific circumstances.</t>
<t>
<t>
In the case of a node that serves simply as a BP "router", the AA may have In the case of a node that serves simply as a BP "router", the AA may have
no application-specific element at all. The application-specific elements no application-specific element at all. The application-specific elements
of other nodes' AAs may perform arbitrarily complex application functions, of other nodes' AAs may perform arbitrarily complex application functions,
perhaps even offering multiplexed DTN communication services to a number of perhaps even offering multiplexed DTN communication services to a number of
other applications. As with the BPA, the manner in which the AA performs other applications. As with the BPA, the manner in which the AA performs
its functions is wholly an implementation matter.</t> its functions is wholly an implementation matter.</t>
<t>
<t>
Singletons are the most familiar sort of endpoint, but in general Singletons are the most familiar sort of endpoint, but in general
the endpoint notion is meant to be broader. For example, the nodes the endpoint notion is meant to be broader. For example, the nodes
in a sensor network might constitute a set of bundle nodes that are in a sensor network might constitute a set of bundle nodes that are
all registered in a single common endpoint and will all receive any all registered in a single common endpoint and will all receive any
data delivered at that endpoint. *Note* too that any given bundle data delivered at that endpoint. <strong>Note</strong> too that any given bun dle
node might be registered in multiple bundle endpoints and receive node might be registered in multiple bundle endpoints and receive
all data delivered at each of those endpoints.</t> all data delivered at each of those endpoints.
</t>
<t>
<t> Recall that every node, by definition, includes an application agent, which
Recall that every node, by definition, includes an application agent which
in turn includes an administrative element, which exchanges administrative in turn includes an administrative element, which exchanges administrative
records with the administrative elements of other nodes. As such, every records with the administrative elements of other nodes. As such, every
node is permanently, structurally registered in the singleton endpoint at node is permanently, structurally registered in the singleton endpoint at
which administrative records received from other nodes are delivered. which administrative records received from other nodes are delivered.
Registration in no other endpoint can ever be assumed to be permanent. Registration in no other endpoint can ever be assumed to be permanent.
This endpoint, termed the node's "administrative endpoint", is therefore This endpoint, termed the node's "administrative endpoint", is therefore
uniquely and permanently associated with the node, and for this reason the uniquely and permanently associated with the node, and for this reason the
ID of a node's administrative endpoint additionally serves as the "node ID" ID of a node's administrative endpoint may always serve as the "node ID"
(see 4.1.5.2 below) of the node.</t> (see <xref target="sect-4.2.5.2"/>) of the node.
</t>
<t> <t>
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 ID is the null endpoint ID are termed "anonymous" bundles.</t> node ID is the null endpoint ID are termed "anonymous" bundles.</t>
<t>
<t>
Any number of transmissions may be concurrently undertaken by the Any number of transmissions may be concurrently undertaken by the
bundle protocol agent of a given node.</t> BPA of a given node.</t>
<t> <t>When the BPA of a node determines that it must forward a bundle either
When the bundle protocol agent of a node determines that a bundle to a node that is a member of the bundle's destination endpoint or to
must be forwarded to a node (either to a node that is a member of some intermediate forwarding node, the BPA invokes the services of one
the bundle's destination endpoint or to some intermediate forwarding or more CLAs in a sustained effort to cause a copy of the bundle to be
node) in the course of completing the successful transmission of received by that node.</t>
that bundle, the bundle protocol agent invokes the services of one
or more CLAs in a sustained effort to cause a copy of the bundle to
be received by that node.</t>
<t> <t>Upon reception, the processing of a bundle depends on whether or not
Upon reception, the processing of a bundle that has been received by the receiving node is registered in the bundle's destination endpoint.
a given node depends on whether or not the receiving node is If it is, and if
registered in the bundle's destination endpoint. If it is, and if
the payload of the bundle is non-fragmentary (possibly as a result the payload of the bundle is non-fragmentary (possibly as a result
of successful payload reassembly from fragmentary payloads, of successful payload reassembly from fragmentary payloads,
including the original payload of the newly received bundle), then including the original payload of the newly received bundle), then
the bundle is normally delivered to the node's application agent the bundle is normally delivered to the node's application agent
subject to the registration characterizing the node's membership in subject to the registration characterizing the node's membership in
the destination endpoint.</t> the destination endpoint.</t>
<t>
<t> The Bundle Protocol itself does not ensure delivery of a bundle to
The bundle protocol does not natively 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, for
end-to-end bundle delivery assurance it will be necessary to develop end-to-end bundle delivery assurance it will be necessary to develop
extensions to the bundle protocol and/or application-layer extensions to the Bundle Protocol and/or application-layer
mechanisms.</t> mechanisms.</t>
<t>
The Bundle Protocol is designed for extensibility. Bundle Protocol
extensions, documented elsewhere, may extend this specification by
defining additional:
<t> </t>
The bundle protocol is designed for extensibility. Bundle protocol <ul spacing="normal">
extensions, documented elsewhere, may extend this specification by: <li>blocks</li>
<li>administrative records</li>
<list style="symbols"> <li>bundle processing control flags</li>
<li>block processing control flags</li>
<t>defining additional blocks;</t> <li>types of bundle status reports</li>
<li>bundle status report reason codes</li>
<t>defining additional administrative records;</t> <li>mandates and constraints on processing that
conformant BPAs must perform at specified points in
<t>defining additional bundle processing flags;</t> the inbound and outbound bundle processing cycles</li>
</ul>
<t>defining additional block processing flags;</t> </section>
<section anchor="sect-3.3" numbered="true" toc="default">
<t>defining additional types of bundle status reports;</t> <name>Services Offered by Bundle Protocol Agents</name>
<t>
<t>defining additional bundle status report reason codes;</t>
<t>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.</t>
</list>
</t>
</section>
<section title="Services Offered by Bundle Protocol Agents" anchor="sect-
3.3"><t>
The BPA of each node is expected to provide the following services The BPA of each node is expected to provide the following services
to the node's application agent: to the node's application agent:
<list style="symbols"> </t>
<ul spacing="normal">
<t>commencing a registration (registering the node in an endpoint);</t> <li>commencing a registration (registering the node in an endpoint).</
li>
<t>terminating a registration;</t> <li>terminating a registration.</li>
<li>switching a registration between Active and Passive states.</li>
<t>switching a registration between Active and Passive states;</t> <li>transmitting a bundle to an identified bundle endpoint.</li>
<li>canceling a transmission.</li>
<t>transmitting a bundle to an identified bundle endpoint;</t> <li>polling a registration that is in the Passive state.</li>
<li>delivering a received bundle.</li>
<t>canceling a transmission;</t> </ul>
<t> Note that the details of registration functionality are an
<t>polling a registration that is in the Passive state;</t>
<t>delivering a received bundle.</t>
</list>
</t>
<t> 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.</t> specification.</t>
</section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
</section> <name>Bundle Format</name>
<section anchor="sect-4.1" numbered="true" toc="default">
<section title="Bundle Format" anchor="sect-4"><section title="Bundle Str <name>Bundle Structure</name>
ucture" anchor="sect-4.1"><t> <t>
The format of bundles SHALL conform to the Concise Binary Object The format of bundles <bcp14>SHALL</bcp14> conform to the Concise Binary Obje
Representation (CBOR <xref target="RFC8949"/>).</t> ct
Representation (CBOR) <xref target="RFC8949" format="default"/>.</t>
<t> <t>
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 <bcp14>MUST</bcp14>
conform to the rules for Canonical CBOR as specified in <xref target="RFC8949 conform to the core deterministic encoding requirements as specified in <xref
"/>.</t> target="RFC8949" format="default"/>, except that indefinite-length items are no
t prohibited.</t>
<t> <t>
Each bundle SHALL be a concatenated sequence of at least two blocks, Each bundle <bcp14>SHALL</bcp14> be a concatenated sequence of at least two b
locks,
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) <bcp14>MUST</bcp14> be a primary b
block in CBOR representation as described below; the bundle MUST undle
have exactly one primary bundle block. The primary block MUST be block in CBOR encoding as described below; the bundle <bcp14>MUST</bcp14>
have exactly one primary bundle block. The primary block <bcp14>MUST</bcp14>
be
followed by one or more canonical bundle blocks (additional array followed by one or more canonical bundle blocks (additional array
items) in CBOR representation as described in 4.3.2 below. Every items) in CBOR encoding as described in <xref target="sect-4.3.2"/>. Every
block following the primary block SHALL be the CBOR representation block following the primary block <bcp14>SHALL</bcp14> be the CBOR encoding
of a canonical block. The last such block MUST be a payload block; of a canonical block. The last such block <bcp14>MUST</bcp14> be a payload b
the bundle MUST have exactly one payload block. The payload block lock;
SHALL be followed by a CBOR "break" stop code, terminating the the bundle <bcp14>MUST</bcp14> have exactly one payload block. The payload b
lock
<bcp14>SHALL</bcp14> be followed by a CBOR "break" stop code, terminating the
array.</t> array.</t>
<aside><t>
<t>
(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 as
inviting increased complexity in protocol data unit structure.)</t> inviting increased complexity in PDU structure.)</t></aside>
<t>
<t>
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 primary block is implicitly zero; the block numbers of all other the 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.</t> the bundle. The block number of the payload block is always 1.</t>
<t>
<t> An implementation of the Bundle Protocol <bcp14>MAY</bcp14> discard any seque
An implementation of the Bundle Protocol MAY discard any sequence of nce of
bytes that does not conform to the Bundle Protocol specification.</t> bytes that does not conform to the Bundle Protocol specification.</t>
<t>
<t> An implementation of the Bundle Protocol <bcp14>MAY</bcp14> accept a sequence
An implementation of the Bundle Protocol MAY accept a sequence of 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.</t> specification.</t>
</section>
</section> <section anchor="sect-4.2" numbered="true" toc="default">
<name>BP Fundamental Data Structures</name>
<section title="BP Fundamental Data Structures" anchor="sect-4.2"><sectio <section anchor="sect-4.2.1" numbered="true" toc="default">
n title="CRC Type" anchor="sect-4.2.1"><t> <name>CRC Type</name>
<t>
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:
<list style="symbols"> </t>
<ul spacing="normal">
<t>0 indicates "no CRC is present."</t> <li>0 indicates "no Cyclic Redundancy Check (CRC) is present."</li>
<li>1 indicates "a standard X-25 CRC-16 is present." <xref target="C
<t>1 indicates "a standard X-25 CRC-16 is present." [CRC16]</t> RC16"/></li>
<li>2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present."
<t>2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." <xref target="RFC4960" format="default"/></li>
<xref target="RFC4960"/></t> </ul>
<t>
</list> CRC type <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer.</t>
</t> <t>
For examples of CRC32C CRCs, see <xref target="RFC7143" sectionFormat="of" se
<t> ction="A.4"/>.</t>
CRC type SHALL be represented as a CBOR unsigned integer.</t> <t>
<t>
For examples of CRC32C CRCs, see Appendix A.4 of <xref target="RFC7143"/>.</t
>
<t>
Note that more robust protection of BP data integrity, as needed, Note that more robust protection of BP data integrity, as needed,
may be provided by means of Block Integrity Blocks as defined in the may be provided by means of Block Integrity Blocks (BIBs) as defined in the
Bundle Security Protocol <xref target="I-D.ietf-dtn-bpsec"/>).</t> Bundle Protocol Security specification <xref target="RFC9172"/>.
</t>
</section> </section>
<section anchor="sect-4.2.2" numbered="true" toc="default">
<section title="CRC" anchor="sect-4.2.2"><t> <name>CRC</name>
CRC SHALL be omitted from a block if and only if the block's CRC <t>
The CRC <bcp14>SHALL</bcp14> be omitted from a block if and only if the block
's CRC
type code is zero.</t> type code is zero.</t>
<t>
<t> When not omitted, the CRC <bcp14>SHALL</bcp14> be represented as a CBOR byte
When not omitted, the CRC SHALL be represented as a CBOR byte string 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 <bcp14>SHALL</bcp14> constitu te 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.</t> byte order.</t>
</section>
</section> <section anchor="sect-4.2.3" numbered="true" toc="default">
<name>Bundle Processing Control Flags</name>
<section title="Bundle Processing Control Flags" anchor="sect-4.2.3"><t> <t>
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.</t> conveyed in the primary block of the bundle.</t>
<t>
<t>
The following properties are asserted by the bundle processing The following properties are asserted by the bundle processing
control flags: control flags:
<list style="symbols"> </t>
<ul spacing="normal">
<t>The bundle is a fragment. (Boolean)</t> <li>The bundle is a fragment. (Boolean)</li>
<li>The bundle's payload is an administrative record. (Boolean)</li
<t>The bundle's payload is an administrative record. (Boolean)</t> >
<li>The bundle must not be fragmented. (Boolean)</li>
<t>The bundle must not be fragmented. (Boolean)</t> <li>Acknowledgment by the user application is requested. (Boolean)<
/li>
<t>Acknowledgment by the user application is requested. (Boolean)</t> <li>Status time is requested in all status reports. (Boolean)</li>
<li>
<t>Status time is requested in all status reports. (Boolean)</t> <t>Flags requesting types of status reports (all Boolean):
<t>Flags requesting types of status reports (all Boolean):
<list style="symbols">
<t>Request reporting of bundle reception.</t>
<t>Request reporting of bundle forwarding.</t>
<t>Request reporting of bundle delivery.</t>
<t>Request reporting of bundle deletion.</t>
</list>
</t>
</list>
</t>
<t> </t>
<ul spacing="normal">
<li>Request reporting of bundle reception.</li>
<li>Request reporting of bundle forwarding.</li>
<li>Request reporting of bundle delivery.</li>
<li>Request reporting of bundle deletion.</li>
</ul>
</li>
</ul>
<t>
If the bundle processing control flags indicate that the bundle's If the bundle processing control flags indicate that the bundle's
application data unit is an administrative record, then all status ADU is an administrative record, then all status
report request flag values MUST be zero.</t> report request flag values <bcp14>MUST</bcp14> be zero.</t>
<t>
<t>
If the bundle's source node is omitted (i.e., the source node ID is the ID If the bundle's source node is omitted (i.e., the source node ID is the ID
of the null endpoint, which has no members as discussed below; this option of the null endpoint, which has no members as discussed below; this option
enables anonymous bundle transmission), then the bundle is not uniquely enables anonymous bundle transmission), then the bundle is not uniquely
identifiable and all bundle protocol features that rely on bundle identity identifiable and all Bundle Protocol features that rely on bundle identity
must therefore be disabled: the "Bundle must not be fragmented" flag value must therefore be disabled: the "Bundle must not be fragmented" flag value
MUST be 1 and all status report request flag values MUST be zero.</t> <bcp14>MUST</bcp14> be 1, and all status report request flag values <bcp14>MU
ST</bcp14> be zero.</t>
<t> <t>
Bundle processing control flags that are unrecognized MUST be Bundle processing control flags that are unrecognized <bcp14>MUST</bcp14> 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.</t> operating at all nodes.</t>
<t>
<t> The bundle processing control flags <bcp14>SHALL</bcp14> be represented as a
The bundle processing control flags SHALL be represented as a CBOR CBOR
unsigned integer item, the value of which SHALL be processed as a unsigned integer item, the value of which <bcp14>SHALL</bcp14> be processed a
s a
bit field indicating the control flag values as follows (note that bit field indicating the control flag values as follows (note that
bit numbering in this instance is reversed from the usual practice, bit 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):
<list style="symbols"> </t>
<dl spacing="normal">
<t>Bit 0 (the low-order bit, 0x000001): bundle is a fragment.</t> <dt>Bit 0 (the low-order bit, 0x000001):</dt>
<dd>Bundle is a fragment.</dd>
<t>Bit 1 (0x000002): payload is an administrative record.</t> <dt>Bit 1 (0x000002):</dt>
<dd>ADU is an administrative record.</dd>
<t>Bit 2 (0x000004): bundle must not be fragmented.</t> <dt>Bit 2 (0x000004):</dt>
<dd>Bundle must not be fragmented.</dd>
<t>Bit 3 (0x000008): reserved.</t> <dt>Bit 3 (0x000008):</dt>
<dd>Reserved.</dd>
<t>Bit 4 (0x000010): reserved.</t> <dt>Bit 4 (0x000010):</dt>
<dd>Reserved.</dd>
<t>Bit 5 (0x000020): user application acknowledgement is requested.</t> <dt>Bit 5 (0x000020):</dt>
<dd>Acknowledgement by application is requested.</dd>
<t>Bit 6 (0x000040): status time is requested in all status reports.</t> <dt>Bit 6 (0x000040):</dt>
<dd>Status time requested in reports.</dd>
<t>Bit 7 (0x000080): reserved.</t> <dt>Bit 7 (0x000080):</dt>
<dd>Reserved.</dd>
<t>Bit 8 (0x000100): reserved.</t> <dt>Bit 8 (0x000100):</dt>
<dd>Reserved.</dd>
<t>Bit 9 (0x000200): reserved.</t> <dt>Bit 9 (0x000200):</dt>
<dd>Reserved.</dd>
<t>Bit 10(0x000400): reserved.</t> <dt>Bit 10 (0x000400):</dt>
<dd>Reserved.</dd>
<t>Bit 11(0x000800): reserved.</t> <dt>Bit 11 (0x000800):</dt>
<dd>Reserved.</dd>
<t>Bit 12(0x001000): reserved.</t> <dt>Bit 12 (0x001000):</dt>
<dd>Reserved.</dd>
<t>Bit 13(0x002000): reserved.</t> <dt>Bit 13 (0x002000):</dt>
<dd>Reserved.</dd>
<t>Bit 14(0x004000): bundle reception status reports are requested.</t> <dt>Bit 14 (0x004000):</dt>
<dd>Request reporting of bundle reception.</dd>
<t>Bit 15(0x008000): reserved.</t> <dt>Bit 15 (0x008000):</dt>
<dd>Reserved.</dd>
<t>Bit 16(0x010000): bundle forwarding status reports are requested.</t> <dt>Bit 16 (0x010000):</dt>
<dd>Request reporting of bundle forwarding.</dd>
<t>Bit 17(0x020000): bundle delivery status reports are requested.</t> <dt>Bit 17 (0x020000):</dt>
<dd>Request reporting of bundle delivery.</dd>
<t>Bit 18(0x040000): bundle deletion status reports are requested.</t> <dt>Bit 18 (0x040000):</dt>
<dd>Request reporting of bundle deletion.</dd>
<t>Bits 19-20 are reserved.</t> <dt>Bits 19-20:</dt>
<dd>Reserved.</dd>
<t>Bits 21-63 are unassigned.</t> <dt>Bits 21-63:</dt>
<dd>Unassigned.</dd>
</list></t> </dl>
</section>
</section> <section anchor="sect-4.2.4" numbered="true" toc="default">
<name>Block Processing Control Flags</name>
<section title="Block Processing Control Flags" anchor="sect-4.2.4"><t> <t>
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 they pertain.</t> which they pertain.</t>
<t>
<t> Block processing control flags that are unrecognized <bcp14>MUST</bcp14> be
Block 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.</t> operating at all nodes.</t>
<t>
<t> The block processing control flags <bcp14>SHALL</bcp14> be represented as a C
The block processing control flags SHALL be represented as a CBOR BOR
unsigned integer item, the value of which SHALL be processed as a unsigned integer item, the value of which <bcp14>SHALL</bcp14> be processed a
s a
bit field indicating the control flag values as follows (note that bit field indicating the control flag values as follows (note that
bit numbering in this instance is reversed from the usual practice, bit 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):</t>
<dl spacing="normal">
<list style="symbols"> <dt>Bit 0 (the low-order bit, 0x01):</dt>
<dd>Block must be replicated in every fragment.</dd>
<t>Bit 0(the low-order bit, 0x01): block must be replicated in every <dt>Bit 1 (0x02):</dt>
fragment.</t> <dd>Transmit status report if block can't be processed.</dd>
<dt>Bit 2 (0x04):</dt>
<t>Bit 1(0x02): transmission of a status report is requested if <dd>Delete bundle if block can't be processed.</dd>
block can't be processed.</t> <dt>Bit 3 (0x08):</dt>
<dd>Reserved.</dd>
<t>Bit 2(0x04): bundle must be deleted if block can't be processed.</t> <dt>Bit 4 (0x10):</dt>
<dd>Discard block if it can't be processed.</dd>
<t>Bit 3(0x08): reserved.</t> <dt>Bit 5 (0x20):</dt>
<dd>Reserved.</dd>
<t>Bit 4(0x10): block must be removed from bundle if it can't be <dt>Bit 6 (0x40):</dt>
processed.</t> <dd>Reserved.</dd>
<dt>Bits 7-63:</dt>
<t>Bit 5(0x20): reserved.</t> <dd>Unassigned.</dd>
</dl>
<t>Bit 6 (0x40): reserved.</t> <t>
<t>Bits 7-63 are unassigned.</t>
</list></t>
<t>
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 is the null endpoint ID as defined below, the whose source node ID is the null endpoint ID as defined below, the
value of the "Transmit status report if block can't be processed" value of the "Transmit status report if block can't be processed"
flag in every canonical block of the bundle MUST be zero.</t> flag in every canonical block of the bundle <bcp14>MUST</bcp14> be zero.</t>
</section>
</section> <section anchor="sect-4.2.5" numbered="true" toc="default">
<name>Identifiers</name>
<section title="Identifiers" anchor="sect-4.2.5"><section title="Endpoint <section anchor="sect-4.2.5.1" numbered="true" toc="default">
ID" anchor="sect-4.2.5.1"><t> <name>Endpoint ID</name>
<t>
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 <xref target="sect-3.1"/>). Each endpoint strings termed "endpoint IDs" (see <xref target="sect-3.1" format="default"/>
ID ). Each endpoint ID
(EID) is a Uniform Resource Identifier (URI; <xref target="URI"/>). As such, (EID) is a Uniform Resource Identifier <xref target="RFC3986" format="default
each "/>. As such, each
endpoint ID can be characterized as having this general structure:</t> endpoint ID can be characterized as having this general structure:</t>
<t>
<t>
&lt; scheme name &gt; : &lt; scheme-specific part, or "SSP" &gt;</t> &lt; scheme name &gt; : &lt; scheme-specific part, or "SSP" &gt;</t>
<t>
<t>
The scheme identified by the &lt; scheme name &gt; in an endpoint ID is a The scheme identified by the &lt; scheme name &gt; 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 be used to
endpoint ID must be added to the registry of URI scheme code numbers form a BP
for Bundle Protocol maintained by IANA as described in <xref target="sect-10" endpoint ID must be added to the "Bundle Protocol URI Scheme Types" registry,
/>; maintained by IANA as described in <xref target="sect-9.6" format="default"/>
;
association of a unique URI scheme code number with each scheme name association of a unique URI scheme code number with each scheme name
in this registry helps to enable compact representation of endpoint in this registry helps to enable compact representation of endpoint
IDs in bundle blocks. Note that the set of allowable schemes is IDs in bundle blocks. Note that the set of allowable schemes is
effectively unlimited. Any scheme conforming to <xref target="URIREG"/> may b effectively unlimited. Any scheme conforming to <xref target="RFC7595" format
e ="default"/> may be
added to the URI scheme code number registry and thereupon used in a added to the registry of URI scheme code numbers and thereupon used in a
bundle protocol endpoint ID.</t> Bundle Protocol endpoint ID.</t>
<t>
<t> Each entry in the registry of URI scheme code numbers <bcp14>MUST</bcp14> con
Each entry in the URI scheme code number registry MUST contain a tain 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 <bcp14>MUST</bcp14> be CBOR encoded
representation, for transmission as a BP endpoint ID. The scheme for transmission as a BP endpoint ID. The scheme
code number definition document may also contain information as to code number definition document may also contain information as to
(a) which convergence-layer protocol(s) may be used to forward a (a) which convergence-layer protocol(s) may be used to forward a
bundle to a BP destination endpoint identified by such an ID, and bundle to a BP destination endpoint identified by such an ID and
(b) how the ID of the convergence-layer protocol endpoint to use for (b) how the ID of the convergence-layer protocol endpoint to use for
that purpose can be inferred from that destination endpoint ID.</t> that purpose can be inferred from that destination endpoint ID.</t>
<t>
<t>
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 <xref target="RFC3987"/>).</t> Identifiers (IRIs); see <xref target="RFC3987" format="default"/>).</t>
<t>
<t> Each BP endpoint ID (EID) <bcp14>SHALL</bcp14> be represented as a CBOR array
Each BP endpoint ID (EID) SHALL be represented as a CBOR array
comprising two items.</t> comprising two items.</t>
<t>
<t> The first item of the array <bcp14>SHALL</bcp14> be the code number identifyi
The first item of the array SHALL be the code number identifying the ng 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 <bcp14>SHA LL</bcp14>
be represented as a CBOR unsigned integer.</t> be represented as a CBOR unsigned integer.</t>
<t>
<t> The second item of the array <bcp14>SHALL</bcp14> be the applicable CBOR
The second item of the array SHALL be the applicable CBOR encoding of the scheme-specific part of the EID, defined
representation of the scheme-specific part (SSP) of the EID, defined
as noted in the references(s) for the URI scheme code number as noted in the references(s) for the URI scheme code number
registry entry for the EID's URI scheme.</t> registry entry for the EID's URI scheme.</t>
<section anchor="sect-4.2.5.1.1" numbered="true" toc="default">
<section title="The &quot;dtn&quot; URI scheme" anchor="sect-4.2.5.1.1">< <name>The dtn URI Scheme</name>
t> <t>
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:</t> follows:</t>
<dl>
<t> <dt>Scheme syntax:</dt>
Scheme syntax: This specification uses the Augmented Backus-Naur <dd>This specification uses the Augmented Backus-Naur
Form (ABNF) notation of <xref target="RFC5234"/>.</t> Form (ABNF) notation of <xref target="RFC5234" format="default"/>.</dd>
</dl>
<figure><artwork><![CDATA[ <sourcecode type="abnf"><![CDATA[
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
]]></artwork> ]]></sourcecode>
</figure> <dl>
<t> <dt>Scheme semantics:</dt>
Scheme semantics: URIs of the dtn scheme are used as endpoint <dd>URIs of the dtn 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.</t> (BP) as described in the present document.</dd>
</dl>
<t> <t>
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.</t> endpoint that by definition never has any members.</t>
<t>
<t>
All BP endpoints identified by all other dtn-scheme endpoint IDs for which All BP endpoints identified by all other dtn-scheme endpoint IDs for which
the first character of demux is a character other than '~' (tilde) are the first character of demux is a character other than '~' (tilde) are
singleton endpoints. All BP endpoints identified by dtn-scheme endpoint IDs singleton endpoints. All BP endpoints identified by dtn-scheme endpoint IDs
for which the first character *is* '~' (tilde) are *not* singleton for which the first character <strong>is</strong> '~' (tilde) are <strong>not </strong> singleton
endpoints.</t> endpoints.</t>
<t>
<t> A dtn-scheme endpoint ID for which the demux is of length zero <bcp14>MAY</bc
A dtn-scheme endpoint ID for which the demux is of length zero MAY p14>
identify the administrative endpoint for the node identified by identify the administrative endpoint for the node identified by
node-name, and as such may serve as a node ID. No dtn-scheme node-name, and as such may serve as a node ID. No dtn-scheme
endpoint ID for which the demux is of non-zero length may do so.</t> endpoint ID for which the demux is of non-zero length may do so.</t>
<t>
<t>
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 <xref target="RFC5050"/>. It is believed that the the dtn scheme as provided in <xref target="RFC5050" format="default"/>. 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
<xref target="RFC5050"/> are in most cases unlikely to be in violation of the se <xref target="RFC5050" format="default"/> 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.</t> potential for compromised interoperation.</t>
<dl>
<t> <dt>Encoding considerations:</dt>
Encoding considerations: For transmission as a BP endpoint ID, the <dd>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 <bcp14>SHALL</bcp14> be repre
sented
as a CBOR text string unless the EID's SSP is "none", in which case as a CBOR text string unless the EID's SSP is "none", in which case
the SSP SHALL be represented as a CBOR unsigned integer with the the SSP <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer with t he
value zero. For all other purposes, URIs of the dtn scheme are value zero. For all other purposes, URIs of the dtn scheme are
encoded exclusively in US-ASCII characters.</t> encoded exclusively in US-ASCII characters.</dd>
<dt>Interoperability considerations:</dt>
<t> <dd>None.</dd>
Interoperability considerations: none.</t> <dt>Security considerations:</dt>
<dd>
<t> <t><br/></t>
Security considerations:</t> <dl>
<dt>Reliability and consistency:</dt>
<t>Reliability and consistency: none of the BP endpoints identified by the <dd>None of the BP endpoints identified by the
URIs of the dtn scheme are guaranteed to be reachable at any time, and the URIs of the dtn scheme are guaranteed to be reachable at any time, and the
identity of the processing entities operating on those endpoints is never identity of the processing entities operating on those endpoints is never
guaranteed by the Bundle Protocol itself. Bundle authentication as defined guaranteed by the Bundle Protocol itself. Verification of the signature provi
by the Bundle Security Protocol is required for this purpose.</t> ded by the Block Integrity Block targeting the bundle's primary block, as define
d by Bundle Protocol Security <xref target="RFC9172"/>, is required for this pur
<t>Malicious construction: malicious construction of a conformant pose.</dd>
<dt>Malicious construction:</dt>
<dd>Malicious construction of a conformant
dtn-scheme URI is limited to the malicious selection of node names and the dtn-scheme URI is limited to the malicious selection of node names and the
malicious selection of demux strings. That is, a maliciously constructed 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 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 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 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 that receives the bundle. In both cases (and indeed in all bundle
processing), the node that receives a bundle should verify its authenticity processing), the node that receives a bundle should verify its authenticity
and validity before operating on it in any way.</t> and validity before operating on it in any way.</dd>
<dt>Back-end transcoding:</dt>
<t>Back-end transcoding: the limited expressiveness of URIs of the dtn <dd>The limited expressiveness of URIs of the dtn
scheme effectively eliminates the possibility of threat due to errors in scheme effectively eliminates the possibility of threat due to errors in
back-end transcoding.</t> back-end transcoding.</dd>
<dt>Rare IP address formats:</dt>
<t>Rare IP address formats: not relevant, as IP addresses do not appear <dd>Not relevant, as IP addresses do not appear
anywhere in conformant dtn-scheme URIs.</t> anywhere in conformant dtn-scheme URIs.</dd>
<dt>Sensitive information:</dt>
<t>Sensitive information: because dtn-scheme URIs are used only to <dd>Because dtn-scheme URIs are used only to
represent the identities of Bundle Protocol endpoints, the risk of represent the identities of Bundle Protocol endpoints, the risk of
disclosure of sensitive information due to interception of these URIs is disclosure of sensitive information due to interception of these URIs is
minimal. Examination of dtn-scheme URIs could be used to support traffic minimal. Examination of dtn-scheme URIs could be used to support traffic
analysis; where traffic analysis is a plausible danger, bundles should be analysis; where traffic analysis is a plausible danger, bundles should be
conveyed by secure convergence-layer protocols that do not expose endpoint conveyed by secure convergence-layer protocols that do not expose endpoint
IDs.</t> IDs.</dd>
<dt>Semantic attacks:</dt>
<t>Semantic attacks: the simplicity of dtn-scheme URI syntax minimizes the <dd>The simplicity of dtn-scheme URI syntax minimizes the
possibility of misinterpretation of a URI by a human user.</t> possibility of misinterpretation of a URI by a human user.</dd>
</dl>
</section> </dd>
</dl>
<section title="The &quot;ipn&quot; URI scheme" anchor="sect-4.2.5.1.2">< </section>
t> <section anchor="sect-4.2.5.1.2" numbered="true" toc="default">
<name>The ipn URI Scheme</name>
<t>
The "ipn" scheme supports the identification of BP endpoints by The "ipn" scheme supports the identification of BP endpoints by
pairs of unsigned integers, for compact representation in bundle pairs of unsigned integers, for compact representation in bundle
blocks. It is specified as follows:</t> blocks. It is specified as follows:</t>
<dl>
<t> <dt>Scheme syntax:</dt>
Scheme syntax: This specification uses the Augmented Backus-Naur <dd>This specification uses the Augmented Backus-Naur
Form (ABNF) notation of <xref target="RFC5234"/>, including the core ABNF syn Form (ABNF) notation of <xref target="RFC5234" format="default"/>, including
tax the core ABNF syntax
rule for DIGIT defined by that specification.</t> rule for DIGIT defined by that specification.</dd>
</dl>
<figure><artwork><![CDATA[ <sourcecode type="abnf"><![CDATA[
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
]]></artwork> ]]></sourcecode>
</figure> <dl>
<t> <dt>Scheme semantics:</dt>
Scheme semantics: URIs of the ipn scheme are used as endpoint <dd>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.</t> (BP) as described in the present document.</dd>
</dl>
<t> <t>
All BP endpoints identified by ipn-scheme endpoint IDs are singleton All BP endpoints identified by ipn-scheme endpoint IDs are singleton
endpoints.</t> endpoints.</t>
<t>
<t> An ipn-scheme endpoint ID for which service-nbr is zero <bcp14>MAY</bcp14> id
An ipn-scheme endpoint ID for which service-nbr is zero MAY identify entify
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.</t> service-nbr is non-zero may do so.</t>
<dl>
<t> <dt>Encoding considerations:</dt>
Encoding considerations: For transmission as a BP endpoint ID, the <dd>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 <bcp14>SHALL</bcp14> 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 EID's node number (a number that identifies this array <bcp14>SHALL</bcp14> be the EID's node number (a number that ident ifies
the node) represented as a CBOR unsigned integer. The second item the node) represented as a CBOR unsigned integer. The second item
of this array SHALL be the EID's service number (a number that of this array <bcp14>SHALL</bcp14> be the EID's service number (a number that
identifies some application service) represented as a CBOR unsigned identifies some application service) represented as a CBOR unsigned
integer. For all other purposes, URIs of the ipn scheme are encoded integer. For all other purposes, URIs of the ipn scheme are encoded
exclusively in US-ASCII characters.</t> exclusively in US-ASCII characters.</dd>
<dt>Interoperability considerations:</dt>
<t> <dd>None.</dd>
Interoperability considerations: none.</t> <dt>Security considerations:</dt>
<dd>
<t> <t><br/></t>
Security considerations:</t> <dl>
<dt>Reliability and consistency:</dt>
<t>Reliability and consistency: none of the BP endpoints identified by the <dd>None of the BP endpoints identified by the
URIs of the ipn scheme are guaranteed to be reachable at any time, and the URIs of the ipn scheme are guaranteed to be reachable at any time, and the
identity of the processing entities operating on those endpoints is never identity of the processing entities operating on those endpoints is never
guaranteed by the Bundle Protocol itself. Bundle authentication as defined guaranteed by the Bundle Protocol itself. Verification of the signature provi
by the Bundle Security Protocol <xref target="I-D.ietf-dtn-bpsec"/> is ded by the Block Integrity Block targeting the bundle's primary block, as define
required for this purpose.</t> d by Bundle Protocol Security <xref target="RFC9172" format="default"/>, is
required for this purpose.</dd>
<t>Malicious construction: malicious construction of a conformant <dt>Malicious construction:</dt>
<dd>Malicious construction of a conformant
ipn-scheme URI is limited to the malicious selection of node numbers and ipn-scheme URI is limited to the malicious selection of node numbers and
the malicious selection of service numbers. That is, a maliciously the malicious selection of service numbers. That is, a maliciously
constructed ipn-scheme URI could be used to direct a bundle to an endpoint 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 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 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 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 bundle processing), the node that receives a bundle should verify its
authenticity and validity before operating on it in any way.</t> authenticity and validity before operating on it in any way.</dd>
<dt>Back-end transcoding:</dt>
<t>Back-end transcoding: the limited expressiveness of URIs of the ipn <dd>The limited expressiveness of URIs of the ipn
scheme effectively eliminates the possibility of threat due to errors in scheme effectively eliminates the possibility of threat due to errors in
back-end transcoding.</t> back-end transcoding.</dd>
<dt>Rare IP address formats:</dt>
<t>Rare IP address formats: not relevant, as IP addresses do not appear <dd>Not relevant, as IP addresses do not appear
anywhere in conformant ipn-scheme URIs.</t> anywhere in conformant ipn-scheme URIs.</dd>
<dt>Sensitive information:</dt>
<t>Sensitive information: because ipn-scheme URIs are used only to <dd>Because ipn-scheme URIs are used only to
represent the identities of Bundle Protocol endpoints, the risk of represent the identities of Bundle Protocol endpoints, the risk of
disclosure of sensitive information due to interception of these URIs is disclosure of sensitive information due to interception of these URIs is
minimal. Examination of ipn-scheme URIs could be used to support traffic minimal. Examination of ipn-scheme URIs could be used to support traffic
analysis; where traffic analysis is a plausible danger, bundles should be analysis; where traffic analysis is a plausible danger, bundles should be
conveyed by secure convergence-layer protocols that do not expose endpoint conveyed by secure convergence-layer protocols that do not expose endpoint
IDs.</t> IDs.</dd>
<dt>Semantic attacks:</dt>
<t>Semantic attacks: the simplicity of ipn-scheme URI syntax minimizes the <dd>The simplicity of ipn-scheme URI syntax minimizes the
possibility of misinterpretation of a URI by a human user. possibility of misinterpretation of a URI by a human user.
</t> </dd>
</dl>
</section> </dd>
</dl>
</section> </section>
</section>
<section title="Node ID" anchor="sect-4.2.5.2"><t> <section anchor="sect-4.2.5.2" numbered="true" toc="default">
For many purposes of the Bundle Protocol it is important to identify <name>Node ID</name>
<t>
For many purposes of the Bundle Protocol, it is important to identify
the node that is operative in some context.</t> the node that is operative in some context.</t>
<t>
<t> As discussed in <xref target="sect-3.1"/>, nodes are distinct from endpoints;
As discussed in 3.1 above, 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 than define a separate namespace for node identifiers, we rather than define a separate namespace for node identifiers, we
instead use endpoint identifiers to identify nodes as discussed in instead use endpoint identifiers to identify nodes as discussed in
3.2 above. Formally: <xref target="sect-3.2"/>. Formally:</t>
<list style="symbols">
<t>Every node is, by definition, permanently registered in the
singleton endpoint at which administrative records are delivered to
its application agent's administrative element, termed the node's
"administrative endpoint".</t>
<t>As such, the EID of a node's administrative endpoint SHALL
uniquely identify that node.</t>
<t>A &quot;node ID&quot; is an EID that identifies the
administrative endpoint of a node.</t>
</list>
</t>
</section>
</section> <ul spacing="normal">
<li>Every node is, by definition, permanently registered in the
singleton endpoint at which administrative records are delivered
to its application agent's administrative element, termed the
node's "administrative endpoint".</li>
<li>As such, the EID of a node's administrative endpoint <bcp14>SHALL</bcp14
>
uniquely identify that node.</li>
<li>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.</li>
</ul>
<section title="DTN Time" anchor="sect-4.2.6"><t> </section>
</section>
<section anchor="sect-4.2.6" numbered="true" toc="default">
<name>DTN Time</name>
<t>
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.</t> 00:00:00 +0000 (UTC). DTN time is not affected by leap seconds.</t>
<t>
<t> Each DTN time <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer
Each DTN time SHALL be represented as a CBOR unsigned integer item. 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<sup>32</sup> - 1); the
manner in which a DTN time value is represented in memory is an manner 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.</t> time is unknown.</t>
</section>
</section> <section anchor="sect-4.2.7" numbered="true" toc="default">
<name>Creation Timestamp</name>
<section title="Creation Timestamp" anchor="sect-4.2.7"><t> <t>
Each bundle's creation timestamp SHALL be represented as a CBOR Each bundle's creation timestamp <bcp14>SHALL</bcp14> be represented as a CBO
R
array comprising two items.</t> array comprising two items.</t>
<t>
<t> The first item of the array, termed "bundle creation time", <bcp14>SHALL</bcp
The first item of the array, termed "bundle creation time", SHALL be 14> 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.</t> unsigned integer.</t>
<t>
<t>
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", <bcp14>SHALL</bcp14> be the latest value (as of the time a t
which the transmission request was received) of a monotonically which the transmission request was received) of a monotonically
increasing positive integer counter managed by the source node's increasing positive integer counter managed by the source node's
bundle protocol agent, represented as a CBOR unsigned integer. The BPA, represented as a CBOR unsigned integer. The
sequence counter MAY be reset to zero whenever the current time sequence counter <bcp14>MAY</bcp14> be reset to zero whenever the current tim
e
advances by one millisecond.</t> advances by one millisecond.</t>
<t>
<t>
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.</t> of the bundle sequence count never be reset to zero.</t>
<t>
<t>
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 identify a single transmission request, enabling it to be to 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).</t> ID is not the null endpoint ID).</t>
</section>
</section> <section anchor="sect-4.2.8" numbered="true" toc="default">
<name>Block-Type-Specific Data</name>
<section title="Block-type-specific Data" anchor="sect-4.2.8"><t> <t>
Block-type-specific data in each block (other than the primary Block-type-specific data in each block (other than the primary
block) SHALL be the applicable CBOR representation of the content of block) <bcp14>SHALL</bcp14> be the applicable CBOR encoding of the content of
the block. Details of this representation are included in the the block. Details of this representation are included in the
specification defining the block type.</t> specification defining the block type.</t>
</section>
</section> </section>
<section anchor="sect-4.3" numbered="true" toc="default">
</section> <name>Block Structures</name>
<t>
<section title="Block Structures" anchor="sect-4.3"><t>
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.</t> <xref target="sect-5"/>.</t>
<t>
<t>
Note that supplementary DTN protocol specifications (including, but Note that supplementary DTN protocol specifications (including, but
not restricted to, the Bundle Security Protocol <xref target="I-D.ietf-dtn-bp sec"/>) may require not restricted to, Bundle Protocol Security <xref target="RFC9172" format="de fault"/>) may require
that BP implementations conforming to those protocols construct and that BP implementations conforming to those protocols construct and
process additional blocks.</t> process additional blocks.</t>
<section anchor="sect-4.3.1" numbered="true" toc="default">
<section title="Primary Bundle Block" anchor="sect-4.3.1"><t> <name>Primary Bundle Block</name>
<t>
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.</t> forward bundles to their destinations.</t>
<t>
<t> Each primary block <bcp14>SHALL</bcp14> be represented as a CBOR array; the n
Each primary block SHALL be represented as a CBOR array; the number umber
of elements in the array SHALL be 8 (if the bundle is not a fragment of elements in the array <bcp14>SHALL</bcp14> be 8 (if the bundle is not a fr
agment
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 no CRC), or 11 (if the bundle is a fragment and the block has a has no CRC), or 11 (if the bundle is a fragment and the block has a
CRC).</t> CRC).</t>
<t>
The primary block of each bundle <bcp14>SHALL</bcp14> be immutable. The CBOR
-
encoded values of all fields in the primary block <bcp14>MUST</bcp14> remain
unchanged from the time the block is created to the time it is
delivered.</t>
<t>
The fields of the primary bundle block <bcp14>SHALL</bcp14> be as follows, li
sted
in the order in which they <bcp14>MUST</bcp14> appear:</t>
<t> <dl>
The primary block of each bundle SHALL be immutable. The CBOR-encoded <dt>Version:</dt>
values of all fields in the primary block MUST remain unchanged from the <dd>An unsigned integer value indicating the version of the
time the block is created to the time it is delivered.</t> Bundle Protocol that constructed this block. The present document
describes BPv7. This version number <bcp14>SHALL</bcp14> be
<t> represented as a CBOR unsigned integer item.</dd>
The fields of the primary bundle block SHALL be as follows, listed <dt>Bundle Processing Control Flags:</dt>
in the order in which they MUST appear:</t> <dd>The bundle processing control flags
are discussed in <xref target="sect-4.2.3" format="default"/>.</dd>
<t> <dt>CRC Type:</dt>
Version: An unsigned integer value indicating the version of the <dd>CRC type codes are discussed in <xref target="sect-4.2.1" format="default
bundle protocol that constructed this block. The present document "/>. The
describes version 7 of the bundle protocol. Version number SHALL be CRC type code for the primary block <bcp14>MAY</bcp14> be zero if the bundle
represented as a CBOR unsigned integer item.</t> contains a BPSec Block Integrity Block <xref target="RFC9172" format="default
"/>
<t> whose target is the
Bundle Processing Control Flags: The Bundle Processing Control Flags primary block; otherwise, the CRC type code for the primary block
are discussed in <xref target="sect-4.2.3"/>. above.</t> <bcp14>MUST</bcp14> be non-zero.</dd>
<dt>Destination EID:</dt>
<t> <dd>The Destination EID field identifies the bundle
CRC Type: CRC Type codes are discussed in <xref target="sect-4.2.1"/>. above.
The
CRC Type code for the primary block MAY be zero if the bundle
contains a BPsec <xref target="I-D.ietf-dtn-bpsec"/> Block Integrity Block wh
ose target is the
primary block; otherwise the CRC Type code for the primary block
MUST be non-zero.</t>
<t>
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.</t> contains the node(s) at which the bundle is to be delivered.</dd>
<dt>Source node ID:</dt>
<t> <dd>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.</t> source chooses to remain anonymous.</dd>
<dt>Report-to EID:</dt>
<t> <dd>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.</t> delivery of this bundle are to be transmitted.</dd>
<dt>Creation Timestamp:</dt>
<t> <dd>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 <xref target="sect-4.2.7"/> for the definition of th
field.</t> is
field.</dd>
<t> <dt>Lifetime:</dt>
Lifetime: The lifetime field is an unsigned integer that indicates <dd>
<t>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 forward
the bundle; the bundle SHOULD be deleted from the network.</t> the bundle; the bundle <bcp14>SHOULD</bcp14> be deleted from the network.</t>
<t>
<t>
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 order to prevent network performance degradation be deleted in order to prevent network performance degradation
(e.g., the bundle appears to be part of a denial-of-service attack), (e.g., the bundle appears to be part of a denial-of-service attack),
then that bundle protocol agent MAY impose a temporary overriding then that BPA <bcp14>MAY</bcp14> impose a temporary overriding
lifetime of shorter duration; such overriding lifetime SHALL NOT lifetime of shorter duration; such an overriding lifetime <bcp14>SHALL NOT</b
replace the lifetime asserted in the bundle but SHALL serve as the cp14>
replace the lifetime asserted in the bundle but <bcp14>SHALL</bcp14> serve as
the
bundle's effective lifetime while the bundle resides at that node. bundle's effective lifetime while the bundle resides at that node.
Procedures for imposing lifetime overrides are beyond the scope of Procedures for imposing lifetime overrides are beyond the scope of
this specification.</t> this specification.</t>
<t>
<t>
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 <xref target="sect-4.4.2"/>) rather than from the differ ence
between current time and bundle creation time. Bundle lifetime between current time and bundle creation time. Bundle lifetime
SHALL be represented as a CBOR unsigned integer item.</t> <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer item.</t>
</dd>
<t> <dt>Fragment offset:</dt>
Fragment offset: If and only if the Bundle Processing Control Flags <dd>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 <bcp14>SHALL</bcp14> be present in the primary block. Fragmen
offset SHALL be represented as a CBOR unsigned integer indicating t
the offset from the start of the original application data unit at offset <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer indicat
which the bytes comprising the payload of this bundle were located.</t> ing
the offset from the start of the original ADU at
which the bytes comprising the payload of this bundle were located.</dd>
<t> <dt>Total Application Data Unit Length:</dt>
Total Application Data Unit Length: If and only if the Bundle <dd>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 <bcp14>SHALL</bcp14>
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 <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer indicating the
length of the original application data unit of which this bundle's total
payload is a part.</t> length of the original ADU of which this bundle's
payload is a part.</dd>
<t> <dt>CRC:</dt>
CRC: A CRC SHALL be present in the primary block unless the bundle includes <dd>A CRC <bcp14>SHALL</bcp14> be present in the primary block unless the bun
a BPsec <xref target="I-D.ietf-dtn-bpsec"/> Block Integrity Block whose dle includes
target is the primary block, in which case a CRC MAY be present in the a BPSec Block Integrity Block <xref target="RFC9172" format="default"/> whose
primary block. The length and nature of the CRC SHALL be as indicated by target is the primary block, in which case a CRC <bcp14>MAY</bcp14> be presen
the CRC type. The CRC SHALL be computed over the concatenation of all t in the
primary block. The length and nature of the CRC <bcp14>SHALL</bcp14> be as i
ndicated by
the CRC type. The CRC <bcp14>SHALL</bcp14> be computed over the concatenatio
n of all
bytes (including CBOR "break" characters) of the primary block including bytes (including CBOR "break" characters) of the primary block including
the CRC field itself, which for this purpose SHALL be temporarily populated the CRC field itself, which, for this purpose, <bcp14>SHALL</bcp14> be tempor
with all bytes set to zero.</t> arily populated
with all bytes set to zero.</dd>
</section> </dl>
<section title="Canonical Bundle Block Format" anchor="sect-4.3.2"><t> </section>
<section anchor="sect-4.3.2" numbered="true" toc="default">
<name>Canonical Bundle Block Format</name>
<t>
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) <bcp14>SHALL</bcp14> be represented as a CBOR array; the
of elements in the array SHALL be 5 (if CRC type is zero) or 6 number
of elements in the array <bcp14>SHALL</bcp14> be 5 (if CRC type is zero) or 6
(otherwise).</t> (otherwise).</t>
<t>
<t> The fields of every canonical block <bcp14>SHALL</bcp14> be as follows, liste
The fields of every canonical block SHALL be as follows, listed in d in
the order in which they MUST appear: the order in which they <bcp14>MUST</bcp14> appear:</t>
<dl>
<list style="symbols"> <dt>Block type code:</dt><dd>An unsigned integer. Bundle block type c
ode 1
<t>Block type code, an unsigned integer. Bundle block type code 1 indicates that the block is a Bundle Payload Block. Other block type cod
indicates that the block is a bundle payload block. Block type codes 2 es
through 9 are explicitly reserved as noted later in this are described in <xref target="sect-9.1" format="default"/>.
specification. Block type codes 192 through 255 are not reserved and Block type codes 192 through 255 are not reserved and
are available for private and/or experimental use. All other block are available for private and/or experimental use. All other block
type code values are reserved for future use.</t> type code values are reserved for future use.</dd>
<dt>Block number:</dt><dd>An unsigned integer as discussed in <xref t
<t>Block number, an unsigned integer as discussed in 4.1 above. Block arget="sect-4.1"/>. The block
number SHALL be represented as a CBOR unsigned integer.</t> number <bcp14>SHALL</bcp14> be represented as a CBOR unsigned integer.</
dd>
<t>Block processing control flags as discussed in Section 4.2.4 <dt>Block processing control flags:</dt><dd>As discussed in <xref tar
above.</t> get="sect-4.2.4"/>.</dd>
<dt>CRC type:</dt><dd>As discussed in <xref target="sect-4.2.1" forma
<t>CRC type as discussed in <xref target="sect-4.2.1"/> above.</t> t="default"/>.</dd>
<dt>Block-type-specific data:</dt><dd>Represented as a single definit
<t>Block-type-specific data represented as a single definite-length e-length
CBOR byte string, i.e., a CBOR byte string that is not of indefinite 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 length. For each type of block, the block-type-specific data byte
string is the serialization, in a block- type-specific manner, of the string is the serialization, in a block-type-specific manner, of the
data conveyed by that type of block; definitions of blocks are data conveyed by that type of block; definitions of blocks are
required to define the manner in which block-type-specific data are required to define the manner in which block-type-specific data are
serialized within the block-type-specific data field. For the Payload serialized within the block-type-specific data field. For the Bundle Pay
Block in particular (block type 1), the block-type-specific data load
field, termed the "payload", SHALL be an application data unit, or Block in particular (block type 1), the block-type-specific data
some contiguous extent thereof, represented as a definite- length CBOR field, termed the "payload", <bcp14>SHALL</bcp14> be an ADU, or
byte string. some contiguous extent thereof, represented as a definite-length CBOR
</t> byte string.</dd>
<dt>If and only if the value of the CRC type field of this block is
<t>If and only if the value of the CRC type field of this block is non-zero:</dt><dd>A CRC. If present, the length and nature of the CRC <b
non-zero, a CRC. If present, the length and nature of the CRC SHALL be cp14>SHALL</bcp14> be
as indicated by the CRC type and the CRC SHALL be computed over the as indicated by the CRC type and the CRC <bcp14>SHALL</bcp14> be compute
concatenation of all bytes of the block (including CBOR "break" d over the
characters) including the CRC field itself, which for this purpose concatenation of all bytes of the block (including CBOR "break"
SHALL be temporarily populated with all bytes set to zero.</t> characters) including the CRC field itself, which, for this purpose,
<bcp14>SHALL</bcp14> be temporarily populated with all bytes set to zero
</list> .</dd>
</t> </dl>
</section>
</section> </section>
<section anchor="sect-4.4" numbered="true" toc="default">
</section> <name>Extension Blocks</name>
<t>"Extension blocks" are all blocks other than the primary and payload
<section title="Extension Blocks" anchor="sect-4.4"><t>
"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) <bcp14>MUST</bcp14> include procedures for recognizing, parsing, an d
acting on, but not necessarily producing, these types of extension acting on, but not necessarily producing, these types of extension
blocks.</t> blocks.</t>
<t>
<t>
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
bundle protocol agent when this is the case.</t> BPA when this is the case.</t>
<t>
<t>
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 <bcp14>MAY</bcp14> insert or remove any
extension block in any bundle, subject to all mandates in the Bundle extension block in any bundle, subject to all mandates in the Bundle
Protocol specification and all extension block specifications to Protocol specification and all extension block specifications to
which the node's BP implementation conforms. Note that removal of which the node's BP implementation conforms. Note that removal of
an extension block will probably disable one or more elements of an extension block will probably disable one or more elements of
bundle processing that were intended by the BPA that inserted that bundle processing that were intended by the BPA that inserted that
block. In particular, note that removal of an extension block that block. In particular, note that removal of an extension block that
is one of the targets of a BPsec security block may render the is one of the targets of a BPSec security block may render the
bundle unverifiable.</t> bundle unverifiable.</t>
<t>
<t>
The following extension blocks are defined in the current document.</t> The following extension blocks are defined in the current document.</t>
<section anchor="sect-4.4.1" numbered="true" toc="default">
<section title="Previous Node" anchor="sect-4.4.1"><t> <name>Previous Node</name>
The Previous Node block, block type 6, identifies the node that <t>
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 <bcp14>SHALL</bcp14> conform to
ID represented as described in <xref target="sect-4.2.5.2"/>. above. If the <xref target="sect-4.2.5.2" format="default"/>.
local If the local
node is the source of the bundle, then the bundle MUST NOT contain node is the source of the bundle, then the bundle <bcp14>MUST NOT</bcp14> con
any Previous Node block. Otherwise the bundle SHOULD contain one tain
(1) occurrence of this type of block and MUST NOT contain more than any Previous Node Block. Otherwise, the bundle <bcp14>SHOULD</bcp14> contain
one
(1) occurrence of this type of block and <bcp14>MUST NOT</bcp14> contain more
than
one.</t> one.</t>
</section>
</section> <section anchor="sect-4.4.2" numbered="true" toc="default">
<name>Bundle Age</name>
<section title="Bundle Age" anchor="sect-4.4.2"><t> <t>
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 in determining the time at which a bundle's lifetime expires. aid in determining the time at which a bundle's lifetime expires.
The block-type-specific data of this block is an unsigned integer The 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 <bcp14>SHALL</bcp14> 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 <bcp14>MUST</bcp14> contain e
one (1) occurrence of this type of block; otherwise, the bundle MAY xactly
one (1) occurrence of this type of block; otherwise, the bundle <bcp14>MAY</b
cp14>
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 <bcp14>MUST NOT</bcp14> contain multiple occurrences of the Bundle Age Block, as
this could result in processing anomalies.</t> this could result in processing anomalies.</t>
</section>
</section> <section anchor="sect-4.4.3" numbered="true" toc="default">
<name>Hop Count</name>
<section title="Hop Count" anchor="sect-4.4.3"><t> <t>
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 <bcp14>MUST</bcp14> be in the range 1 through 255. The hop limit value
NOT be changed at any time after creation of the Hop Count block; <bcp14>SHOULD
the hop count value SHOULD initially be zero and SHOULD be increased NOT</bcp14> be changed at any time after creation of the Hop Count Block;
the hop count value <bcp14>SHOULD</bcp14> initially be zero and <bcp14>SHOULD
</bcp14> be increased
by 1 on each hop.</t> by 1 on each hop.</t>
<t>
<t> 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 of identifying bundles for removal from the network that can means of identifying bundles for removal from the network that can
never be delivered due to a persistent forwarding error. Hop count never be delivered due to a persistent forwarding error. The hop count
is particularly valuable as a defense against routing anomalies that is 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 limit, the bundle SHOULD be deleted for the reason "hop limit exceeded", hop limit, the bundle <bcp14>SHOULD</bcp14> be deleted for the reason "Hop li
following the bundle deletion procedure defined in mit exceeded", following the Bundle Deletion procedure defined in
<xref target="sect-5.10"/>.</t> <xref target="sect-5.10" format="default"/>.</t>
<t>
<t>
Procedures for determining the appropriate hop limit for a bundle Procedures for determining the appropriate hop limit for a bundle
are beyond the scope of this specification.</t> are beyond the scope of this specification.</t>
<t>
<t> The block-type-specific data in a Hop Count Block <bcp14>SHALL</bcp14> 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 <bcp14>SHALL</bcp14> be the bundle's hop limit, represented as a C
unsigned integer. The second item of this array SHALL be the BOR
unsigned integer. The second item of this array <bcp14>SHALL</bcp14> 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 <bcp14>MAY</bcp14> contain one occurrence of this type of block but <bcp14>MU ST NOT</bcp14>
contain more than one.</t> contain more than one.</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-5" numbered="true" toc="default">
<name>Bundle Processing</name>
</section> <t>
The bundle-processing procedures mandated in this section and in
<section title="Bundle Processing" anchor="sect-5"><t> <xref target="sect-6" format="default"/> govern the operation of the BPA and
The bundle processing procedures mandated in this section and in the
<xref target="sect-6"/> govern the operation of the Bundle Protocol Agent and application agent administrative element of each bundle node. They
the
Application Agent administrative element of each bundle node. They
are neither exhaustive nor exclusive. Supplementary DTN protocol are neither exhaustive nor exclusive. Supplementary DTN protocol
specifications (including, but not restricted to, the Bundle specifications (including, but not restricted to, Bundle Protocol
Security Protocol <xref target="I-D.ietf-dtn-bpsec"/>) may augment, override, Security <xref target="RFC9172" format="default"/>) may augment, override, or
or supersede the supersede the
mandates of this document.</t> mandates of this document.</t>
<section anchor="sect-5.1" numbered="true" toc="default">
<section title="Generation of Administrative Records" anchor="sect-5.1">< <name>Generation of Administrative Records</name>
t> <t>
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), the bundle protocol agent itself is responsible for causing report), the BPA itself is responsible for causing
a new bundle to be transmitted, conveying that record. In concept, a new bundle to be transmitted, conveying that record. In concept,
the bundle protocol agent discharges this responsibility by the BPA discharges this responsibility by
directing the administrative element of the node's application agent directing the administrative element of the node's application agent
to construct the record and request its transmission as detailed in to construct the record and request its transmission as detailed in
<xref target="sect-6"/> below. In practice, the manner in which administrativ e <xref target="sect-6" format="default"/>. In practice, the manner in which ad ministrative
record generation is accomplished is an implementation matter, record generation is accomplished is an implementation matter,
provided the constraints noted in <xref target="sect-6"/> are observed.</t> provided the constraints noted in <xref target="sect-6" format="default"/> ar
e observed.</t>
<t> <t>
Status reports are relatively small bundles. Moreover, even when Status reports are relatively small bundles. Moreover, even when
the generation of status reports is enabled the decision on whether the generation of status reports is enabled, the decision on whether
or not to generate a requested status report is left to the or not to generate a requested status report is left to the
discretion of the bundle protocol agent. Nonetheless, note that discretion of the BPA. Nonetheless, note that
requesting status reports for any single bundle might easily result requesting status reports for any single bundle might easily result
in the generation of (1 + (2 *(N-1))) status report bundles, where N in the generation of (1 + (2 *(N-1))) status report bundles, where N
is the number of nodes on the path from the bundle's source to its is the number of nodes on the path from the bundle's source to its
destination, inclusive. That is, the requesting of status reports destination, inclusive. That is, the requesting of status reports
for large numbers of bundles could result in an unacceptable for large numbers of bundles could result in an unacceptable
increase in the bundle traffic in the network. For this reason, the increase in the bundle traffic in the network. For this reason, the
generation of status reports MUST be disabled by default and enabled generation of status reports <bcp14>MUST</bcp14> be disabled by default and e nabled
only when the risk of excessive network traffic is deemed only when the risk of excessive network traffic is deemed
acceptable. Mechanisms that could assist in assessing and acceptable. Mechanisms that could assist in assessing and
mitigating this risk, such as pre-placed agreements authorizing the mitigating this risk, such as pre-placed agreements authorizing the
generation of status reports under specified circumstances, are generation of status reports under specified circumstances, are
beyond the scope of this specification.</t> beyond the scope of this specification.</t>
<t> <t>Notes on administrative record terminology:</t>
Notes on administrative record terminology: <ul spacing="normal">
<li>A "bundle reception status report" is a bundle status report with
<list style="symbol"> the "Reporting node received bundle" flag set to 1.</li>
<li>A "bundle forwarding status report" is a bundle status report
<t>A "bundle reception status report is a bundle status report with with the "Reporting node forwarded the bundle" flag set to 1.</li>
the "reporting node received bundle" flag set to 1.</t> <li>A "bundle delivery status report" is a bundle status report with
the "Reporting node delivered the bundle" flag set to 1.</li>
<t>A "bundle forwarding status report" is a bundle status report <li>A "bundle deletion status report" is a bundle status report with
with the "reporting node forwarded the bundle" flag set to 1.</t> the "Reporting node deleted the bundle" flag set to 1.</li>
</ul>
<t>A "bundle delivery status report" is a bundle status report with </section>
the "reporting node delivered the bundle" flag set to 1.</t> <section anchor="sect-5.2" numbered="true" toc="default">
<name>Bundle Transmission</name>
<t>A "bundle deletion status report" is a bundle status report with <t>
the "reporting node deleted the bundle" flag set to 1.</t> The steps in processing a bundle transmission request are as follows:</t
>
</list> <ol type="Step %d:" indent="9">
</t> <li>
Transmission of the bundle is initiated. An outbound bundle
</section> <bcp14>MUST</bcp14> be created per the parameters of the bundle transmission
<section title="Bundle Transmission" anchor="sect-5.2"><t>
The steps in processing a bundle transmission request are:</t>
<t>
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 request, with the retention constraint "Dispatch pending". The
source node ID of the bundle MUST be either the null endpoint ID, source node ID of the bundle <bcp14>MUST</bcp14> be either (a) the null endpo
indicating that the source of the bundle is anonymous, or else the int 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 EID of a singleton endpoint whose only member is the node of which
the BPA is a component.</t> the BPA is a component.</li>
<t>
Step 2: Processing proceeds from Step 1 of <xref target="sect-5.4"/>.</t>
</section> <li> Processing proceeds from Step 1 of <xref target="sect-5.4" format="defaul
t"/>.</li>
</ol>
<section title="Bundle Dispatching" anchor="sect-5.3"><t> </section>
<section anchor="sect-5.3" numbered="true" toc="default">
<name>Bundle Dispatching</name>
<t>
(Note that this procedure is initiated only following completion of (Note that this procedure is initiated only following completion of
Step 4 of <xref target="sect-5.6"/>.)</t> Step 4 of <xref target="sect-5.6" format="default"/>.)</t>
<t>
<t> The steps in dispatching a bundle are as follows:</t>
The steps in dispatching a bundle are:</t> <ol type="Step %d:" indent="9">
<li>
<t> 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 in <xref target="sect-5.7" format="default"/> <bcp14>MUST</bcp14> be followed an
<xref target="sect-5.7"/> MUST be followed and for the purposes of all subseq d, for the purposes of all subsequent
uent processing of this bundle at this node, the node's membership in the
processing of this bundle at this node the node's membership in the bundle's destination endpoint <bcp14>SHALL</bcp14> be disavowed; specifically
bundle's destination endpoint SHALL be disavowed; specifically, even , even
though the node is a member of the bundle's destination endpoint, though the node is a member of the bundle's destination endpoint,
the node SHALL NOT undertake to forward the bundle to itself in the the node <bcp14>SHALL NOT</bcp14> undertake to forward the bundle to itself i
course of performing the procedure described in <xref target="sect-5.4"/>.</t n the
> course of performing the procedure described in <xref target="sect-5.4" forma
t="default"/>.</li>
<t>
Step 2: Processing proceeds from Step 1 of <xref target="sect-5.4"/>.</t>
</section> <li> Processing proceeds from Step 1 of <xref target="sect-5.4" format
="default"/>.</li>
</ol>
<section title="Bundle Forwarding" anchor="sect-5.4"><t> </section>
The steps in forwarding a bundle are:</t> <section anchor="sect-5.4" numbered="true" toc="default">
<name>Bundle Forwarding</name>
<t>
The steps in forwarding a bundle are as follows:</t>
<ol type="Step %d:" indent="9">
<t> <li>The retention constraint "Forward pending" <bcp14>MUST</bcp14> 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 constraint
MUST be removed.</t> <bcp14>MUST</bcp14> be removed.</li>
<li><t>The BPA <bcp14>MUST</bcp14> determine whether or not
<t>
Step 2: The bundle protocol agent MUST determine whether or not
forwarding is contraindicated (that is, rendered inadvisable) for forwarding is contraindicated (that is, rendered inadvisable) for
any of the reasons listed in the IANA registry of Bundle Status any of the reasons listed in the IANA "Bundle Status Report Reason Codes" reg
Report Reason Codes (see section 10.5 below), whose initial contents istry
are listed in Figure 4. In particular: (see <xref target="sect-9.5"/>), whose initial contents
are listed in <xref target="tab-1"/>. In particular:</t>
<list style="symbols">
<t>The bundle protocol agent MAY choose either to forward the bundle
directly to its destination node(s) (if possible) or to forward the
bundle to some other node(s) for further forwarding. The manner in
which this decision is made may depend on the scheme name in the
destination endpoint ID and/or on other state but in any case is
beyond the scope of this document; one possible mechanism is
described in [SABR]. If the BPA elects to forward the bundle to some
other node(s) for further forwarding but finds it impossible to
select any node(s) to forward the bundle to, then forwarding is
contraindicated.</t>
<t>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 <xref target="I-D.ietf-dtn-tcpclv4"/> 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.</t>
</list>
</t>
<t>
Step 3: If forwarding of the bundle is determined to be
contraindicated for any of the reasons listed in the IANA registry
of Bundle Status Report Reason Codes (see section 10.5 below), then
the Forwarding Contraindicated procedure defined in <xref target="sect-5.4.1"
/>
MUST be followed; the remaining steps of <xref target="sect-5.4"/> are skippe
d at
this time.</t>
<t>
Step 4: For each node selected for forwarding, the bundle protocol
agent MUST invoke the services of the selected convergence layer
adapter(s) in order to effect the sending of the bundle to that
node. Determining the time at which the bundle protocol agent
invokes convergence layer adapter services is a BPA implementation
matter. Determining the time at which each convergence layer
adapter subsequently responds to this service invocation by sending
the bundle is a convergence-layer adapter implementation matter.
Note that:
<list style="symbols">
<t>If the bundle has a Previous Node block, as defined in 4.4.1
above, then that block MUST be removed from the bundle before the
bundle is forwarded.</t>
<t>If the bundle protocol agent is configured to attach Previous
Node blocks to forwarded bundles, then a Previous Node block
containing the node ID of the forwarding node MUST be inserted into
the bundle before the bundle is forwarded.</t>
<t>If the bundle has a bundle age block, as defined in 4.4.2. <ul spacing="normal">
above, then at the last possible moment before the CLA initiates <li>The BPA <bcp14>MAY</bcp14> choose to either forward the bundle
conveyance of the bundle via the CL protocol the bundle age value directly to its destination node(s) (if possible) or forward the
MUST be increased by the difference between the current time and the bundle to some other node(s) for further forwarding. The manner in
time at which the bundle was received (or, if the local node is the which this decision is made may depend on the scheme name in the
source of the bundle, created).</t> destination endpoint ID and/or on other state but in any case is
beyond the scope of this document; one possible mechanism is
described in <xref target="SABR"/>. If the BPA elects to forward the b
undle to some
other node(s) for further forwarding but finds it impossible to
select any node(s) to forward the bundle to, then forwarding is
contraindicated.</li>
<li>Provided the BPA succeeded in selecting the
node or nodes to forward the bundle to, the BPA <bcp14>MUST</bcp14>
subsequently select the CLA(s) whose services
will enable the node to send the bundle to those nodes. The manner
in which specific appropriate CLAs are
selected is beyond the scope of this document; the TCP
CLA <xref target="RFC9174" format="default"/> <bcp14>MUST</bcp14>
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 f
orwarding this bundle, then forwarding
is contraindicated.</li>
</ul>
</li>
</list> <li>
</t> If forwarding of the bundle is determined to be
contraindicated for any of the reasons listed in the IANA "Bundle Status Repo
rt
Reason Codes" registry (see <xref target="sect-9.5"/>), then
the Forwarding Contraindicated procedure defined in <xref target="sect-5.4.1"
format="default"/>
<bcp14>MUST</bcp14> be followed; the remaining steps of this Bundle Forwardin
g procedure are skipped at this time.</li>
<t> <li><t>For each node selected for forwarding, the BPA <bcp14>MUST</bcp14> invo
Step 5: When all selected convergence layer adapters have informed ke the services of the selected CLA(s) in order to effect the sending of the bun
the bundle protocol agent that they have concluded their data dle to that
sending procedures with regard to this bundle, processing may depend node. Determining the time at which the BPA
on the results of those procedures.</t> invokes CLA services is a BPA implementation
matter. Determining the time at which each CLA subsequently responds to this
service invocation by sending
the bundle is a CLA implementation matter.
Note that:</t>
<t> <ul spacing="normal">
If completion of the data sending procedures by all selected <li>If the bundle has a Previous Node Block, as defined in <xref targe
convergence layer adapters has not resulted in successful forwarding t="sect-4.4.1"/>,
then that block <bcp14>MUST</bcp14> be removed from the bundle before
the
bundle is forwarded.</li>
<li>If the BPA is configured to attach Previous
Node Blocks to forwarded bundles, then a Previous Node Block
containing the node ID of the forwarding node <bcp14>MUST</bcp14> be i
nserted into
the bundle before the bundle is forwarded.</li>
<li>If the bundle has a Bundle Age Block, as defined in <xref target="
sect-4.4.2"/>,
then at the last possible moment before the CLA initiates
conveyance of the bundle via the CL protocol the bundle age value
<bcp14>MUST</bcp14> 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).</li>
</ul>
</li>
<li>
When all selected CLAs have informed
the BPA that they have concluded their data-sending procedures
with regard to this bundle, processing may depend on the results of those
procedures.</li>
</ol>
<t>
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 of the bundle (an implementation-specific determination that is
beyond the scope of this specification), then the bundle protocol beyond the scope of this specification), then the BPA <bcp14>MAY</bcp14> choo
agent MAY choose (in an implementation-specific manner, again beyond se (in an implementation-specific manner, again beyond
the scope of this specification) to initiate another attempt to the scope of this specification) to initiate another attempt to
forward the bundle. In that event, processing proceeds from Step 4. forward the bundle. In that event, processing proceeds from Step 4.
The minimum number of times a given node will initiate another The minimum number of times a given node will initiate another
forwarding attempt for any single bundle in this event (a number forwarding attempt for any single bundle in this event (a number
which may be zero) is a node configuration parameter that must be 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 exposed to other nodes in the network to the extent that this is
required by the operating environment.</t> required by the operating environment.</t>
<t>
<t> If completion of the data-sending procedures by all selected
If completion of the data sending procedures by all selected CLAs <strong>HAS</strong> resulted in successful forwarding of
convergence layer adapters HAS resulted in successful forwarding of the bundle, or if it has not but the BPA does not
the bundle, or if it has not but the bundle protocol agent does not
choose to initiate another attempt to forward the bundle, then: choose to initiate another attempt to forward the bundle, then:
</t>
<ul spacing="normal">
<li>If the "request reporting of bundle forwarding" flag in the
bundle's status report request field is set to 1 and status
reporting is enabled, then a bundle forwarding status report <bcp14>SH
OULD</bcp14>
be generated, destined for the bundle's report-to endpoint ID. The
reason code on this bundle forwarding status report <bcp14>MUST</bcp14
> be "no
additional information".</li>
<li>If any applicable Bundle Protocol extensions mandate generation
of status reports upon conclusion of convergence-layer data-sending
procedures, all such status reports <bcp14>SHOULD</bcp14> be generated
with
extension-mandated reason codes.</li>
<li>The bundle's "Forward pending" retention constraint <bcp14>MUST</b
cp14> be
removed.</li>
</ul>
<section anchor="sect-5.4.1" numbered="true" toc="default">
<name>Forwarding Contraindicated</name>
<t>
The steps in responding to contraindication of forwarding are as follows:</t>
<list style="symbols"> <ol type="Step %d:" indent="9">
<li>The BPA <bcp14>MUST</bcp14> determine whether or not to
<t>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
reporting is enabled, then a bundle forwarding status report SHOULD
be generated, destined for the bundle's report-to endpoint ID. The
reason code on this bundle forwarding status report MUST be "no
additional information".</t>
<t>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.</t>
<t>The bundle's "Forward pending" retention constraint MUST be
removed.</t>
</list>
</t>
<section title="Forwarding Contraindicated" anchor="sect-5.4.1"><t>
The steps in responding to contraindication of forwarding are:</t>
<t>
Step 1: The bundle protocol agent 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 likely to be influenced by the reason for which forwarding is
contraindicated.</t> contraindicated.</li>
<li>
<t> If forwarding failure is declared, then the Forwarding
Step 2: If forwarding failure is declared, then the Forwarding Failed procedure defined in <xref target="sect-5.4.2" format="default"
Failed procedure defined in <xref target="sect-5.4.2"/> MUST be followed.</t> /> <bcp14>MUST</bcp14> be followed.</li>
</ol>
<t> <t>
Otherwise, when - at some future time - the forwarding of this 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 <xref target="sect-5.4"/>.</t> of <xref target="sect-5.4" format="default"/>.</t>
</section>
<section title="Forwarding Failed" anchor="sect-5.4.2"><t>
The steps in responding to a declaration of forwarding failure are:</t>
<t> </section>
Step 1: The bundle protocol agent MAY forward the bundle back to the <section anchor="sect-5.4.2" numbered="true" toc="default">
node that sent it, as identified by the Previous Node block, if <name>Forwarding Failed</name>
present. This forwarding, if performed, SHALL be accomplished by <t>
performing Step 4 and Step 5 of section 5.4 where the sole node The steps in responding to a declaration of forwarding failure are as follows
selected for forwarding SHALL be the node that sent the bundle.</t> :</t>
<t> <ol type="Step %d:" indent="9">
Step 2: If the bundle's destination endpoint is an endpoint of which <li>The BPA <bcp14>MAY</bcp14> forward the bundle back to the
node that sent it, as identified by the Previous Node Block, if
present. This forwarding, if performed, <bcp14>SHALL</bcp14> be accomplished
by
performing Step 4 and Step 5 of <xref target="sect-5.4"/> where the sole node
selected for forwarding <bcp14>SHALL</bcp14> be the node that sent the bundle
.</li>
<li>
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" retention
constraint MUST be removed. Otherwise, the bundle MUST be deleted: constraint <bcp14>MUST</bcp14> be removed. Otherwise, the bundle <bcp14>MUST<
the bundle deletion procedure defined in <xref target="sect-5.10"/> MUST be /bcp14> be deleted:
the Bundle Deletion procedure defined in <xref target="sect-5.10" format="def
ault"/> <bcp14>MUST</bcp14> be
followed, citing the reason for which forwarding was determined to followed, citing the reason for which forwarding was determined to
be contraindicated.</t> be contraindicated.</li>
</ol>
</section> </section>
</section>
</section> <section anchor="sect-5.5" numbered="true" toc="default">
<name>Bundle Expiration</name>
<section title="Bundle Expiration" anchor="sect-5.5"><t> <t>
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. Bundle age
protocol agent. Bundle age MAY be determined by subtracting the <bcp14>MAY</bcp14> be determined by subtracting the
bundle's creation timestamp time from the current time if (a) that bundle's creation timestamp time from the current time if (a) that
timestamp time is not zero and (b) the local node's clock is known timestamp time is not zero and (b) the local node's clock is known
to be accurate; otherwise bundle age MUST be obtained from the to be accurate; otherwise, bundle age <bcp14>MUST</bcp14> be obtained from th
Bundle Age extension block. Bundle expiration MAY occur at any e
Bundle Age extension block. Bundle expiration <bcp14>MAY</bcp14> occur at an
y
point in the processing of a bundle. When a bundle expires, the point in the processing of a bundle. When a bundle expires, the
bundle protocol agent MUST delete the bundle for the reason BPA <bcp14>MUST</bcp14> delete the bundle for the reason
"lifetime expired" (when the expired lifetime is the lifetime as "Lifetime expired" (when the expired lifetime is the lifetime as
specified in the primary block) or "traffic pared" (when the expired specified in the primary block) or "Traffic pared" (when the expired
lifetime is a lifetime override as imposed by the bundle protocol lifetime is a lifetime override as imposed by the BPA): the Bundle Deletion p
agent): the bundle deletion procedure defined in <xref target="sect-5.10"/> M rocedure defined in <xref target="sect-5.10" format="default"/> <bcp14>MUST</bcp
UST 14>
be followed.</t> be followed.</t>
</section>
</section> <section anchor="sect-5.6" numbered="true" toc="default">
<name>Bundle Reception</name>
<section title="Bundle Reception" anchor="sect-5.6"><t> <t>
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:</t> node are as follows:</t>
<ol type="Step %d:" indent="9">
<t> <li>The retention constraint "Dispatch pending" <bcp14>MUST</bcp14> be added
Step 1: The retention constraint "Dispatch pending" MUST be added to to
the bundle.</t> the bundle.</li>
<li>
<t> 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 with
reason code "No additional information" SHOULD be generated, reason code "No additional information" <bcp14>SHOULD</bcp14> be generated,
destined for the bundle's report-to endpoint ID.</t> destined for the bundle's report-to endpoint ID.</li>
<li>
<t> CRCs <bcp14>SHOULD</bcp14> 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 malformed
according to this specification (including syntactically invalid according to this specification (including syntactically invalid
CBOR), or if any block has an attached CRC and the CRC computed for CBOR), or if any block has an attached CRC and the CRC computed for
this block upon reception differs from that attached CRC, then the this block upon reception differs from that attached CRC, then the
bundle protocol agent MUST delete the bundle for the reason "Block unintellig BPA <bcp14>MUST</bcp14> delete the bundle for the reason "Block unintelligibl
ible". The bundle deletion procedure defined in <xref target="sect-5.10"/> MUST e". The Bundle Deletion procedure defined in <xref target="sect-5.10" format="d
be followed and all remaining steps of the bundle efault"/> <bcp14>MUST</bcp14> be followed, and all remaining steps of the Bundle
reception procedure MUST be skipped.</t> Reception procedure <bcp14>MUST</bcp14> be skipped.</li>
<li>
<t> <t>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 BPA cannot process:</t>
the bundle protocol agent cannot process:
<list style="symbols">
<t>If the block processing flags in that block indicate that a
status report is requested in this event, and status reporting is
enabled, then a bundle reception status report with reason code
"Block unsupported" SHOULD be generated, destined for the bundle's
report-to endpoint ID.</t>
<t>If the block processing flags in that block indicate that the
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 <xref target="sect-5.10"/> MUST
be followed and all remaining steps of the bundle reception
procedure MUST be skipped.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
<t> <ul spacing="normal">
Step 5: Processing proceeds from Step 1 of <xref target="sect-5.3"/>.</t> <li>If the block processing control flags in that block indicate that
a
status report is requested in this event and if status reporting is
enabled, then a bundle reception status report with reason code
"Block unsupported" <bcp14>SHOULD</bcp14> be generated, destined for t
he bundle's
report-to endpoint ID.</li>
<li>If the block processing control flags in that block indicate that
the
bundle must be deleted in this event, then the BPA
<bcp14>MUST</bcp14> delete the bundle for the reason "Block unsupporte
d"; the
Bundle Deletion procedure defined in <xref target="sect-5.10" format="
default"/> <bcp14>MUST</bcp14>
be followed, and all remaining steps of the Bundle Reception
procedure <bcp14>MUST</bcp14> be skipped.</li>
<li>If the block processing control flags in that block do <strong>NOT
</strong> indicate that
the bundle must be deleted in this event but do indicate that the
block must be discarded, then the BPA <bcp14>MUST</bcp14> remove
this block from the bundle.</li>
<li>If the block processing control flags in that block neither indica
te 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.</li>
</ul>
</li>
</section> <li>
Processing proceeds from Step 1 of <xref target="sect-5.3" format="defau
lt"/>.</li>
</ol>
<section title="Local Bundle Delivery" anchor="sect-5.7"><t> </section>
<section anchor="sect-5.7" numbered="true" toc="default">
<name>Local Bundle Delivery</name>
<t>
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:</t> which this node is a member are as follows:</t>
<ol type="Step %d:" indent="9">
<t> <li>
Step 1: If the received bundle is a fragment, the application data If the received bundle is a fragment, the ADU Reassembly procedure described
unit reassembly procedure described in <xref target="sect-5.9"/> MUST be foll in <xref target="sect-5.9" format="default"/> <bcp14>MUST</bcp14> be followed.
owed.
If this procedure results in reassembly of the entire original If 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 been replaced by the reassembled application data unit payload has been replaced by the reassembled ADU
(whether this bundle or a previously received fragment) proceeds (whether this bundle or a previously received fragment) proceeds
from Step 2; otherwise, the retention constraint "Reassembly pending" MUST be from Step 2; otherwise, the retention constraint "Reassembly pending" <bcp14>
added to the bundle and all remaining steps of this MUST</bcp14> be added to the bundle, and all remaining steps of this
procedure MUST be skipped.</t> procedure <bcp14>MUST</bcp14> be skipped.</li>
<li>
<t> <t>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:</t>
endpoint ID matches that of the destination of the bundle:
<list style="symbols">
<t>An additional implementation-specific delivery deferral procedure
MAY optionally be associated with the registration.</t>
<t>If the registration is in the Active state, then the bundle MUST
be delivered automatically as soon as it is the next bundle that is
due for delivery according to the BPA's bundle delivery scheduling
policy, an implementation matter.</t>
<t>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:
<list style="symbols">
<t>defer delivery of the bundle subject to this registration
until (a) this bundle is the least recently received of all
bundles currently deliverable subject to this registration and
(b) either the registration is polled or else the registration
is in the Active state, and also perform any additional
delivery deferral procedure associated with the registration;
or</t>
<t>abandon delivery of the bundle subject to this registration
(as defined in 3.1. ).</t>
</list>
</t>
</list> <ul spacing="normal">
</t> <li>An additional implementation-specific delivery deferral procedure
<bcp14>MAY</bcp14> optionally be associated with the registration.</li
>
<li>If the registration is in the Active state, then the bundle <bcp14
>MUST</bcp14>
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).</li>
<li>
<t>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 <bcp14>MUST</bcp14> be taken. T
he
delivery failure action <bcp14>MUST</bcp14> be one of the following:
</t>
<ul spacing="normal">
<li>Defer delivery of the bundle subject to this registration
until (a) this bundle is the least recently received of all
bundles currently deliverable subject to this registration and
(b) either the registration is polled or the registration
is in the Active state, and also perform any additional
delivery deferral procedure associated with the registration,
or</li>
<li>Abandon delivery of the bundle subject to this registration
(as defined in <xref target="sect-3.1"/>).</li>
</ul>
</li>
</ul>
</li>
<t> <li>
Step 3: As soon as the bundle has been delivered, if the "request reporting o As soon as the bundle has been delivered, if the "request reporting of bundle
f bundle delivery" flag in the bundle's status report delivery" flag in the bundle's status report
request field is set to 1 and bundle status reporting is enabled, request field is set to 1 and bundle status reporting is enabled,
then a bundle delivery status report SHOULD be generated, destined then a bundle delivery status report <bcp14>SHOULD</bcp14> be generated, dest ined
for the bundle's report-to endpoint ID. Note that this status report for the bundle's report-to endpoint ID. Note that this status report
only states that the payload has been delivered to the application only states that the payload has been delivered to the application
agent, not that the application agent has processed that payload.</t> agent, not that the application agent has processed that payload.</li>
</ol>
</section>
<section title="Bundle Fragmentation" anchor="sect-5.8"><t> </section>
It may at times be advantageous for bundle protocol agents to reduce <section anchor="sect-5.8" numbered="true" toc="default">
<name>Bundle Fragmentation</name>
<t>
It may at times be advantageous for BPAs to reduce
the sizes of bundles in order to forward them. This might be the 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 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 accessible only via intermittent contacts and no upcoming contact is
long enough to enable the forwarding of the entire bundle.</t> long enough to enable the forwarding of the entire bundle.</t>
<t>
<t>
The size of a bundle can be reduced by "fragmenting" the bundle. To 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 <bcp14>MUST</bcp1
4> 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 &lt; N &lt; M.</t> payload, where 0 &lt; N &lt; M.</t>
<t>
<t>
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.)</t> there is only one "level" of fragmentation, as in IP fragmentation.)</t>
<t>
<t> Any bundle whose primary block's bundle processing control flags do <strong>N
Any bundle whose primary block's bundle processing flags do NOT OT</strong>
indicate that it must not be fragmented MAY be fragmented at any indicate that it must not be fragmented <bcp14>MAY</bcp14> be fragmented at a
time, for any purpose, at the discretion of the bundle protocol ny
agent. NOTE, however, that some combinations of bundle time, for any purpose, at the discretion of the BPA. <strong>NOTE</strong>,
however, that some combinations of bundle
fragmentation, replication, and routing might result in unexpected fragmentation, replication, and routing might result in unexpected
traffic patterns.</t> traffic patterns.</t>
<t>
Fragmentation <bcp14>SHALL</bcp14> be constrained as follows:
<t> </t>
Fragmentation SHALL be constrained as follows: <ul spacing="normal">
<li>The concatenation of the payloads of all fragments produced by
<list style="symbols"> fragmentation <bcp14>MUST</bcp14> always be identical to the payload o
f the
<t>The concatenation of the payloads of all fragments produced by fragmented bundle (that is, the bundle that is being
fragmentation MUST always be identical to the payload of the fragmented). Note that the payloads of fragments resulting from
fragmented bundle (that is, the bundle that is being different fragmentation episodes, in different parts of the network,
fragmented). Note that the payloads of fragments resulting from may be overlapping subsets of the fragmented bundle's payload.</li>
different fragmentation episodes, in different parts of the network, <li>The primary block of each fragment <bcp14>MUST</bcp14> differ from
may be overlapping subsets of the fragmented bundle's payload.</t> that of the
fragmented bundle, in that the bundle processing control flags of the
<t>The primary block of each fragment MUST differ from that of the fragment <bcp14>MUST</bcp14> indicate that the bundle is a fragment an
fragmented bundle, in that the bundle processing flags of the d both
fragment MUST indicate that the bundle is a fragment and both fragment offset and total application data unit length must be
fragment offset and total application data unit length must be provided. Additionally, the CRC of the primary block of the
provided. Additionally, the CRC of the primary block of the fragmented bundle, if any, <bcp14>MUST</bcp14> be replaced in each fra
fragmented bundle, if any, MUST be replaced in each fragment by a gment by a
new CRC computed for the primary block of that fragment.</t> new CRC computed for the primary block of that fragment.</li>
<li>The payload blocks of fragments will differ from that of the
<t>The payload blocks of fragments will differ from that of the fragmented bundle as noted above.</li>
fragmented bundle as noted above.</t> <li>If the fragmented bundle is not a fragment or is the fragment
with offset zero, then all extension blocks of the fragmented bundle
<t>If the fragmented bundle is not a fragment or is the fragment <bcp14>MUST</bcp14> be replicated in the fragment whose offset is zero
with offset zero, then all extension blocks of the fragmented bundle .</li>
MUST be replicated in the fragment whose offset is zero.</t> <li>Each of the fragmented bundle's extension blocks whose "Block
must be replicated in every fragment" flag is set to 1 <bcp14>MUST</bc
<t>Each of the fragmented bundle's extension blocks whose "Block p14> be
must be replicated in every fragment" flag is set to 1 MUST be replicated in every fragment. </li>
replicated in every fragment. </t> <li>Beyond these rules, rules for the replication of extension blocks
in the fragments must be defined in the specifications for those
<t>Beyond these rules, rules for the replication of extension blocks extension block types.</li>
in the fragments must be defined in the specifications for those </ul>
extension block types.</t> </section>
<section anchor="sect-5.9" numbered="true" toc="default">
</list> <name>Application Data Unit Reassembly</name>
</t> <t>
Note that the Bundle Fragmentation procedure described in <xref target="sect-
</section> 5.8"/>
<section title="Application Data Unit Reassembly" anchor="sect-5.9"><t>
Note that the bundle fragmentation procedure described in 5.8 above
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.</t> be reassembled from the payloads of those fragments.</t>
<t>
<t>
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 whose length is equal to the total application data unit array whose length is equal to the total application data unit
length noted in the fragment's primary block, then: length noted in the fragment's primary block, then:
<list style="symbols"> </t>
<ul spacing="normal">
<t>This byte array -- the reassembled application data unit -- <li>This byte array -- the reassembled ADU --
MUST replace the payload of that fragment whose material extents <bcp14>MUST</bcp14> replace the payload of that fragment whose materia
include the extent at offset zero. Note that this will enable l extents
delivery of the reconstituted original bundle as described in Step 1 include the extent at offset zero. Note that this will enable
of 5.7.</t> delivery of the reconstituted original bundle as described in Step 1
of <xref target="sect-5.7"/>.</li>
<t>The "Reassembly pending" retention constraint MUST be removed <li>The "Reassembly pending" retention constraint <bcp14>MUST</bcp14>
from every other fragment with the same source node ID and creation be removed
timestamp as this fragment.</t> from every other fragment with the same source node ID and creation
timestamp as this fragment.</li>
</list> </ul>
</t> <t>
Note: Reassembly of ADUs from fragments occurs at
<t>
Note: reassembly of application data units from fragments occurs at
the nodes that are members of destination endpoints as necessary; an the nodes that are members of destination endpoints as necessary; an
application data unit MAY also be reassembled at some other node on ADU <bcp14>MAY</bcp14> also be reassembled at some other node on
the path to the destination.</t> the path to the destination.</t>
</section>
</section> <section anchor="sect-5.10" numbered="true" toc="default">
<name>Bundle Deletion</name>
<section title="Bundle Deletion" anchor="sect-5.10"><t> <t>
The steps in deleting a bundle are:</t> The steps in deleting a bundle are as follows:</t>
<ol type="Step %d:" indent="9">
<t> <li>
Step 1: If the "request reporting of bundle deletion" flag in the If the "request reporting of bundle deletion" flag in the
bundle's status report request field is set to 1, and if status bundle's status report request field is set to 1 and if status
reporting is enabled, then a bundle deletion status report citing reporting is enabled, then a bundle deletion status report citing
the reason for deletion SHOULD be generated, destined for the the reason for deletion <bcp14>SHOULD</bcp14> be generated, destined for the
bundle's report-to endpoint ID.</t> bundle's report-to endpoint ID.</li>
<li>
<t> All of the bundle's retention constraints <bcp14>MUST</bcp14> be removed
Step 2: All of the bundle's retention constraints MUST be removed.</t> .</li>
</ol>
</section> </section>
<section anchor="sect-5.11" numbered="true" toc="default">
<section title="Discarding a Bundle" anchor="sect-5.11"><t> <name>Discarding a Bundle</name>
As soon as a bundle has no remaining retention constraints it MAY be <t>
As soon as a bundle has no remaining retention constraints, it <bcp14>MAY</bc
p14> be
discarded, thereby releasing any persistent storage that may have discarded, thereby releasing any persistent storage that may have
been allocated to it.</t> been allocated to it.</t>
</section>
</section> <section anchor="sect-5.12" numbered="true" toc="default">
<name>Canceling a Transmission</name>
<section title="Canceling a Transmission" anchor="sect-5.12"><t> <t>
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 <bcp14>MUST</bcp14> delete that bundle
for the reason "transmission cancelled". For this purpose, the for the reason "Transmission canceled". For this purpose, the
procedure defined in <xref target="sect-5.10"/> MUST be followed.</t> procedure defined in <xref target="sect-5.10" format="default"/> <bcp14>MUST<
/bcp14> be followed.</t>
</section> </section>
</section>
</section> <section anchor="sect-6" numbered="true" toc="default">
<name>Administrative Record Processing</name>
<section title="Administrative Record Processing" anchor="sect-6"><sectio <section anchor="sect-6.1" numbered="true" toc="default">
n title="Administrative Records" anchor="sect-6.1"><t> <name>Administrative Records</name>
Administrative records are standard application data units that are <t>
used in providing some of the features of the Bundle Protocol. One Administrative records are standard ADUs that are
type of administrative record has been defined to date: bundle used in providing some of the features of the Bundle Protocol.
status reports. Note that additional types of administrative Bundle Protocol administrative record types are registered in the
IANA "Bundle Administrative Record Types" registry <xref target="RFC5050"/>;
of these, only administrative record type 1, "Bundle status report", is defin
ed
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.</t> documents.</t>
<t>
<t>
Every administrative record consists of: Every administrative record consists of:
<list style="symbols"> </t>
<ul spacing="normal">
<t>Record type code (an unsigned integer for which valid values are <li>A record type code (an unsigned integer for which valid values are
as defined below).</t> as defined below).</li>
<li>Record content in type-specific format.</li>
<t>Record content in type-specific format.</t> </ul>
<t>
</list> Each BP administrative record <bcp14>SHALL</bcp14> be represented as a CBOR a
</t> rray
<t>
Valid administrative record type codes are defined as follows:</t>
<figure title="Administrative Record Type Codes" anchor="fig-3">
<artwork><![CDATA[
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 1 | Bundle status report. |
+---------+--------------------------------------------+
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
]]></artwork>
</figure>
<t>
Each BP administrative record SHALL be represented as a CBOR array
comprising two items.</t> comprising two items.</t>
<t>
<t> The first item of the array <bcp14>SHALL</bcp14> be a record type code, which
The first item of the array SHALL be a record type code, which SHALL <bcp14>SHALL</bcp14>
be represented as a CBOR unsigned integer.</t> be represented as a CBOR unsigned integer.</t>
<t>
<t> The second element of this array <bcp14>SHALL</bcp14> be the applicable CBOR
The second element of this array SHALL be the applicable CBOR encoding of the content of the record. Details of the CBOR
representation of the content of the record. Details of the CBOR encoding of administrative record type 1 are provided below.
representation of administrative record type 1 are provided below. Details of the CBOR encoding of other types of administrative
Details of the CBOR representation of other types of administrative records are included in the specifications defining those
record type are included in the specifications defining those
records.</t> records.</t>
<section anchor="sect-6.1.1" numbered="true" toc="default">
<section title="Bundle Status Reports" anchor="sect-6.1.1"><t> <name>Bundle Status Reports</name>
<t>
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.</t> bundles.</t>
<t>
<t> Each bundle status report <bcp14>SHALL</bcp14> be represented as a CBOR array
Each bundle status report SHALL be represented as a CBOR array. The . The
number of elements in the array SHALL be either 6 (if the subject number of elements in the array <bcp14>SHALL</bcp14> be either 6 (if the subj
ect
bundle is a fragment) or 4 (otherwise).</t> bundle is a fragment) or 4 (otherwise).</t>
<t>
<t> The first element of the bundle status report <bcp14>SHALL</bcp14> be bundle
The first item of the bundle status report array SHALL be bundle status information represented as a CBOR array of at least four
status information represented as a CBOR array of at least 4 elements. The first four elements of the bundle status information
elements. The first four items of the bundle status information shall provide information on the following four status
array shall provide information on the following four status
assertions, in this order: assertions, in this order:
<list style="symbols"> </t>
<ul spacing="normal">
<t>Reporting node received bundle.</t> <li>Reporting node received bundle.</li>
<li>Reporting node forwarded the bundle.</li>
<t>Reporting node forwarded the bundle.</t> <li>Reporting node delivered the bundle.</li>
<li>Reporting node deleted the bundle.</li>
<t>Reporting node delivered the bundle.</t> </ul>
<t>
<t>Reporting node deleted the bundle.</t> Each element of the bundle status information <bcp14>SHALL</bcp14> be a bundl
e
</list> status item encoded as a CBOR array.</t>
</t> <t>The number of elements in
each bundle status item <bcp14>SHALL</bcp14> be either 2 (if the value of the
<t> first element of
Each item of the bundle status information array SHALL be a bundle the bundle status item is 1 AND the "Report status time" flag was
status item represented as a CBOR array; the number of elements in set to 1 in the bundle processing control flags of the bundle whose status
each such array SHALL be either 2 (if the value of the first item of is being reported) or 1 (otherwise).</t>
this bundle status item is 1 AND the "Report status time" flag was <t>The first element of each bundle status item <bcp14>SHALL</bcp14>
set to 1 in the bundle processing flags of the bundle whose status be a status indicator, a Boolean value indicating whether or not the
is being reported) or 1 (otherwise). The first item of the bundle corresponding bundle status is asserted, encoded as a CBOR Boolean value.
status item array SHALL be a status indicator, a Boolean value If present, the second element of each bundle status item
indicating whether or not the corresponding bundle status is <bcp14>SHALL</bcp14> indicate the time (as reported by the local system clock
asserted, represented as a CBOR Boolean value. The second item of ;
the bundle status item array, if present, SHALL indicate the time this is an implementation matter) at which the indicated status was asserted
(as reported by the local system clock, an implementation matter) at for
which the indicated status was asserted for this bundle, represented this bundle, represented as a DTN time as described in <xref target="sect-4.2
as a DTN time as described in <xref target="sect-4.2.6"/>. above.</t> .6" format="default"/>.</t>
<t>
<t> The second element of the bundle status report <bcp14>SHALL</bcp14> be the
The second item of the bundle status report array SHALL be the
bundle status report reason code explaining the value of the status bundle status report reason code explaining the value of the status
indicator, represented as a CBOR unsigned integer. Valid status indicator, represented as a CBOR unsigned integer. Valid status
report reason codes are registered in the IANA Bundle Status Report report reason codes are registered in the IANA "Bundle Status Report
Reason Codes registry in the Bundle Protocol Namespace (see 10.5 Reason Codes" subregistry in the "Bundle Protocol" registry (see <xref target
below). The initial contents of that registry are listed in Figure ="sect-9.5"/>). The initial contents of that registry are listed in <xref targe
4 below but the list of status report reason codes provided here is t="tab-1"/>, but the list of status report reason codes provided here is
neither exhaustive nor exclusive; supplementary DTN protocol neither exhaustive nor exclusive; supplementary DTN protocol
specifications (including, but not restricted to, the Bundle specifications (including, but not restricted to, Bundle Protocol
Security Protocol <xref target="I-D.ietf-dtn-bpsec"/>) may define additional Security <xref target="RFC9172" format="default"/>) may define additional rea
reason codes.</t> son codes.</t>
<table anchor="tab-1" align="left">
<figure title="Status Report Reason Codes" anchor="fig-4"><artwork><![CDATA[ <name>Status Report Reason Codes</name>
<thead>
+---------+--------------------------------------------+ <tr>
<th>Value</th>
| Value | Meaning | <th>Meaning</th>
</tr>
+=========+============================================+ </thead>
<tbody>
| 0 | No additional information. | <tr>
<td>0</td>
+---------+--------------------------------------------+ <td>No additional information.</td>
</tr>
| 1 | Lifetime expired. | <tr>
<td>1</td>
+---------+--------------------------------------------+ <td>Lifetime expired.</td>
</tr>
| 2 | Forwarded over unidirectional link. | <tr>
<td>2</td>
+---------+--------------------------------------------+ <td>Forwarded over unidirectional link.</td>
</tr>
| 3 | Transmission canceled. | <tr>
<td>3</td>
+---------+--------------------------------------------+ <td>Transmission canceled.</td>
</tr>
| 4 | Depleted storage. | <tr>
<td>4</td>
+---------+--------------------------------------------+ <td>Depleted storage.</td>
</tr>
| 5 | Destination endpoint ID unavailable. | <tr>
<td>5</td>
+---------+--------------------------------------------+ <td>Destination endpoint ID unavailable.</td>
</tr>
| 6 | No known route to destination from here. | <tr>
<td>6</td>
+---------+--------------------------------------------+ <td>No known route to destination from here.</td>
</tr>
| 7 | No timely contact with next node on route. | <tr>
<td>7</td>
+---------+--------------------------------------------+ <td>No timely contact with next node on route.</td>
</tr>
| 8 | Block unintelligible. | <tr>
<td>8</td>
+---------+--------------------------------------------+ <td>Block unintelligible.</td>
</tr>
| 9 | Hop limit exceeded. | <tr>
<td>9</td>
+---------+--------------------------------------------+ <td>Hop limit exceeded.</td>
</tr>
| 10 | Traffic pared (e.g., status reports). | <tr>
<td>10</td>
+---------+--------------------------------------------+ <td>Traffic pared (e.g., status reports).</td>
</tr>
| 11 | Block unsupported. | <tr>
<td>11</td>
+---------+--------------------------------------------+ <td>Block unsupported.</td>
</tr>
| (other) | Reserved for future use. | <tr>
<td>17-254</td>
<td>Unassigned</td>
</tr>
<tr>
<td>255</td>
<td>Reserved</td>
</tr>
</tbody>
</table>
+---------+--------------------------------------------+ <t>
]]></artwork> The third element of the bundle status report <bcp14>SHALL</bcp14> be the sou
</figure> rce
<t>
The third item of the bundle status report array 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 <xref target="sect-4.2.5.1.1"/>. above. reported, represented as described in <xref target="sect-4.2.5.1.1" format="d
</t> efault"/>.</t>
<t>
<t> The fourth element of the bundle status report <bcp14>SHALL</bcp14> be the
The fourth item of the bundle status report array SHALL be the
creation timestamp of the bundle whose status is being reported, creation timestamp of the bundle whose status is being reported,
represented as described in <xref target="sect-4.2.7"/>. above.</t> represented as described in <xref target="sect-4.2.7" format="default"/>.</t>
<t>
<t> The fifth element of the bundle status report <bcp14>SHALL</bcp14> be present
The fifth item of the bundle status report array SHALL be present if if
and only if the bundle whose status is being reported contained a and only if the bundle whose status is being reported contained a
fragment offset. If present, it SHALL be the subject bundle's fragment offset. If present, it <bcp14>SHALL</bcp14> be the subject bundle's
fragment offset represented as a CBOR unsigned integer item.</t> fragment offset represented as a CBOR unsigned integer item.</t>
<t>
<t> The sixth element of the bundle status report <bcp14>SHALL</bcp14> be present
The sixth item of the bundle status report array SHALL be present if if
and only if the bundle whose status is being reported contained a and 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 <bcp14>SHALL</bcp14> be the length of the su bject
bundle's payload represented as a CBOR unsigned integer item.</t> bundle's payload represented as a CBOR unsigned integer item.</t>
<t>
<t>
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 MAY be reflected in the parameters governing the forwarding reported <bcp14>MAY</bcp14> be reflected in the parameters governing the forw arding
of the bundle that conveys a status report, but this is an of the bundle that conveys a status report, but this is an
implementation matter. Bundle protocol deployment experience to implementation matter. Bundle Protocol deployment experience to
date has not been sufficient to suggest any clear guidance on this date has not been sufficient to suggest any clear guidance on this
topic.</t> topic.</t>
</section>
</section> </section>
<section anchor="sect-6.2" numbered="true" toc="default">
</section> <name>Generation of Administrative Records</name>
<t>
<section title="Generation of Administrative Records" anchor="sect-6.2"><
t>
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 procedure must be followed:</t> the following procedure must be followed:</t>
<ol type="Step %d:" indent="9">
<t> <li>
Step 1: The administrative record must be constructed. If the The administrative record must be constructed. If the
administrative record references a bundle and the referenced bundle administrative record references a bundle and the referenced bundle
is a fragment, the administrative record MUST contain the fragment is a fragment, the administrative record <bcp14>MUST</bcp14> contain the frag
offset and fragment length.</t> ment
offset and fragment length.</li>
<t> <li>
Step 2: A request for transmission of a bundle whose payload is this A request for transmission of a bundle whose payload is this
administrative record MUST be presented to the bundle protocol administrative record <bcp14>MUST</bcp14> be presented to the BPA.</li>
agent.</t> </ol>
</section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
</section> <name>Services Required of the Convergence Layer</name>
<section anchor="sect-7.1" numbered="true" toc="default">
<section title="Services Required of the Convergence Layer" anchor="sect- <name>The Convergence Layer</name>
7"><section title="The Convergence Layer" anchor="sect-7.1"><t> <t>
The successful operation of the end-to-end bundle protocol depends The successful operation of the end-to-end Bundle Protocol depends
on the operation of underlying protocols at what is termed the on the operation of underlying protocols at what is termed the
"convergence layer"; these protocols accomplish communication "convergence layer"; these protocols accomplish communication
between nodes. A wide variety of protocols may serve this purpose, between nodes. A wide variety of protocols may serve this purpose,
so long as each convergence layer protocol adapter provides a so long as each CLA provides a
defined minimal set of services to the bundle protocol agent. This defined minimal set of services to the BPA. This
convergence layer service specification enumerates those services.</t> convergence-layer service specification enumerates those services.</t>
</section>
</section> <section anchor="sect-7.2" numbered="true" toc="default">
<name>Summary of Convergence-Layer Services</name>
<section title="Summary of Convergence Layer Services" anchor="sect-7.2"> <t>
<t> Each CLA is expected to provide the
Each convergence layer protocol adapter is expected to provide the following services to the BPA:
following services to the bundle protocol agent:
<list style="symbols">
<t>sending a bundle to a bundle node that is reachable via the
convergence layer protocol;</t>
<t>notifying the bundle protocol agent of the disposition of its
data sending procedures with regard to a bundle, upon concluding
those procedures;</t>
<t>delivering to the bundle protocol agent a bundle that was sent by
a bundle node via the convergence layer protocol.</t>
</list>
</t>
<t> </t>
The convergence layer service interface specified here is neither <ul spacing="normal">
<li>sending a bundle to a bundle node that is reachable via the
convergence-layer protocol.</li>
<li>notifying the BPA of the disposition of its
data-sending procedures with regard to a bundle, upon concluding
those procedures.</li>
<li>delivering to the BPA a bundle that was sent by
a bundle node via the convergence-layer protocol.</li>
</ul>
<t>
The convergence-layer service interface specified here is neither
exhaustive nor exclusive. That is, supplementary DTN protocol exhaustive nor exclusive. That is, supplementary DTN protocol
specifications (including, but not restricted to, the Bundle specifications (including, but not restricted to, Bundle Protocol
Security Protocol <xref target="I-D.ietf-dtn-bpsec"/>) may expect convergence Security <xref target="RFC9172" format="default"/>) may expect CLAs
layer adapters
that serve BP implementations conforming to those protocols to that serve BP implementations conforming to those protocols to
provide additional services such as reporting on the transmission provide additional services such as reporting on the transmission
and/or reception progress of individual bundles (at completion and/or reception progress of individual bundles (at completion
and/or incrementally), retransmitting data that were lost in and/or incrementally), retransmitting data that were lost in
transit, discarding bundle-conveying data units that the convergence transit, discarding bundle-conveying data units that the
layer protocol determines are corrupt or inauthentic, or reporting convergence-layer protocol determines are corrupt or inauthentic, or reportin
g
on the integrity and/or authenticity of delivered bundles.</t> on the integrity and/or authenticity of delivered bundles.</t>
<t>
<t> In addition, the Bundle Protocol relies on the capabilities of protocols at t
In addition, bundle protocol relies on the capabilities of protocols at the he
convergence layer to minimize congestion in the store-carry-forward overlay convergence layer to minimize congestion in the store-carry-forward overlay
network. The potentially long round-trip times characterizing network. The potentially long round-trip times characterizing
delay-tolerant networks are incompatible with end-to- end reactive delay-tolerant networks are incompatible with end-to-end, reactive
congestion control mechanisms, so convergence-layer protocols MUST provide congestion-control mechanisms, so convergence-layer protocols <bcp14>MUST</bc
p14> provide
rate limiting or congestion control.</t> rate limiting or congestion control.</t>
</section>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>
<section title="Implementation Status" anchor="sect-8"><t> The Bundle Protocol security architecture and the available security
[NOTE to the RFC Editor: please remove this section before publication, as we services are specified in an accompanying document, the Bundle Protocol Secur
ll as the reference to RFC 7942.]</t> ity
(BPSec) specification <xref target="RFC9172" format="default"/>. Whenever Bu
<t> ndle
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.</t>
<t>
According to RFC 7942, "this will allow reviewers and working groups to assig
n due consideration to documents that have the benefit of running code, which ma
y serve as evidence of valuable experimentation and feedback that have made the
implemented protocols more mature. It is up to the individual working groups to
use this information as they see fit".</t>
<t>
At the time of this writing, there are six known implementations of
the current document.</t>
<t>
The first known implementation is microPCN (<eref target="https://upcn.eu/"/>
).
According to the developers:</t>
<t>
The Micro Planetary Communication Network (uPCN) is a free 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
<list style="symbols">
<t>the Bundle Protocol (BP, RFC 5050),</t>
<t>version 6 of the Bundle Protocol version 7 specification draft,</t>
<t>the DTN IP Neighbor Discovery (IPND) protocol, and</t>
<t>a routing approach optimized for message-ferry micro LEO
satellites.</t>
</list>
</t>
<t>
uPCN is written in C and is built upon the real-time operating
system FreeRTOS. The source code of uPCN is released under the
"BSD 3-Clause License".</t>
<t>
The project depends on an execution environment offering link
layer protocols such as AX.25. The source code uses the USB
subsystem to interact with the environment.</t>
<t>
The second known implementation is PyDTN, developed by X-works,
s.r.o (<eref target="https://x-works.sk/"/>). The final third of the impleme
ntation
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.</t>
<t>
The third known implementation is "Terra"
(<eref target="https://github.com/RightMesh/Terra/"/>), a Java implementation
developed in the context of terrestrial DTN. It includes an
implementation of a "minimal TCP" convergence layer adapter.</t>
<t>
The fourth and fifth known implementations are products of
cooperating groups at two German universities:
<list style="symbols">
<t>An implementation written in Go, licensed under GPLv3, is focused
on being easily extensible suitable for research. It is maintained
at the University of Marburg and can be accessed from <eref
target="https://github.com/dtn7/dtn7-go."/> </t>
<t>An implementation written in Rust, licensed under the MIT/Apache
license, is intended for environments with limited resources or
demanding safety and/or performance requirements. It is maintained
at the Technical University of Darmstadt and can be accessed at
<eref target="https://github.com/dtn7/dtn7-rs/."/> </t>
</list>
</t>
<t>
The sixth known implementation is the "bpv7" module in version 4.0.0
of the Interplanetary Overlay Network (ION) software maintained at
the Jet Propulsion Laboratory, California Institute of Technology,
for the U.S. National Aeronautics and Space Administration (NASA).</t>
</section>
<section title="Security Considerations" anchor="sect-9"><t>
The bundle protocol security architecture and the available security
services are specified in an accompanying document, the Bundle
Security Protocol (BPsec) specification <xref target="I-D.ietf-dtn-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 <bcp14>SHALL</bcp14
provided by BPsec rather than by some other mechanism with the same > be
provided by BPSec rather than by some other mechanism with the same
or similar scope.</t> or similar scope.</t>
<t>
<t> A Bundle Protocol Agent (BPA) that sources, cryptographically
A Bundle Protocol Agent (BPA) which sources, cryptographically verifies, and/or accepts a bundle <bcp14>MUST</bcp14> implement support for B
verifies, and/or accepts a bundle MUST implement support for BPsec. PSec.
Use of BPsec for a particular Bundle Protocol session is optional.</t> Use of BPSec for any single bundle is optional.</t>
<t>
<t> The BPSec extensions to the Bundle Protocol enable each block of a
The BPsec extensions to 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).</t> encrypted by a Block Confidentiality Block (BCB).</t>
<t>
<t>
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.</t> forwarding opportunity, as well as in transit.</t>
<t>
<t>
Additionally, convergence-layer protocols that ensure authenticity Additionally, convergence-layer protocols that ensure authenticity
of communication between adjacent nodes in BP network topology of communication between adjacent nodes in a BP network topology
SHOULD be used where available, to minimize the ability of <bcp14>SHOULD</bcp14> be used where available, to minimize the ability of
unauthenticated nodes to introduce inauthentic traffic into the unauthenticated nodes to introduce inauthentic traffic into the
network. Convergence-layer protocols that ensure confidentiality of network. 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 <bcp14>SHOULD</ bcp14>
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.</t> defense against traffic analysis.</t>
<t>
<t>
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 peer(s).
These must be supplied by the convergence-layer adapter. Details of These must be supplied by the CLA. Details of
the means by which the CLA determines which CL endpoint name(s) must the means by which the CLA determines which CL endpoint name(s) must
be provided to the CL protocol are out of scope for this be provided to the CL protocol are out of scope for this
specification. Note, though, that when the CL endpoint names are a specification. Note, though, that when the CL endpoint names are a
function of BP endpoint IDs, the correctness and authenticity of function of BP endpoint IDs, the correctness and authenticity of
that mapping will be vital to the overall security properties that that mapping will be vital to the overall security properties that
the CL provides to the system.</t> the CL provides to the system.</t>
<t>
<t>
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 <xref target="I-D.ietf-dtn-bibect"/> to tunnel bundles to a saf e forward encapsulation <xref target="I-D.ietf-dtn-bibect" format="default"/> to tunnel bundles to a safe forward
distribution point: the encapsulated bundle could form the payload distribution point: the encapsulated bundle could form the payload
of an encapsulating bundle, and that payload block could be of an encapsulating bundle, and that payload block could be
encrypted by a BCB.</t> encrypted by a BCB.</t>
<t>
<t>
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 result in the transmission of extremely large numbers of could result in the transmission of extremely large numbers of
bundles, effecting a denial of service attack. Imposing bundle bundles, effecting a denial-of-service attack. Imposing bundle
lifetime overrides would constitute one defense against such an lifetime overrides would constitute one defense against such an
attack.</t> attack.</t>
<t>
<t>
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, occupying storage while pending reassembly that will never attack, occupying storage while pending reassembly that will never
occur. Imposing bundle lifetime overrides would, again, constitute occur. Imposing bundle lifetime overrides would, again, constitute
one defense against such an attack.</t> one defense against such an attack.</t>
<t>
<t>
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.</t> their clock is inaccurate may exhibit unexpected behavior.</t>
</section>
</section> <section anchor="sect-9" numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations" anchor="sect-10"><t> <t>
The Bundle Protocol includes fields requiring registries managed by The Bundle Protocol includes fields requiring registries managed by
IANA.</t> IANA.</t>
<section anchor="sect-9.1" numbered="true" toc="default">
<name>Bundle Block Types</name>
<t>
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 <xref target="sect-4.3.1"/>, to the "Bundle Block Types" registr
y
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.</t>
<table align="left">
<name>"Bundle Block Types" Registry</name>
<thead>
<tr>
<th>Bundle Protocol Version</th>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>none</td>
<td>0</td>
<td>Reserved</td>
<td><xref target="RFC6255"/></td>
</tr>
<tr>
<section title="Bundle Block Types" anchor="sect-10.1"><t> <td>6,7</td>
The current Bundle Block Types registry in the Bundle Protocol <td>1</td>
Namespace is augmented by adding a column identifying the version of <td>Bundle Payload Block</td>
the Bundle protocol (Bundle Protocol Version) that applies to the <td><xref target="RFC5050"/> [RFC9171]</td>
new values. IANA is requested to add the following values, as </tr>
described in section 4.3.1, to the Bundle Block Types registry. The <tr>
current values in the Bundle Block Types registry should have the
Bundle Protocol Version set to the value "6", as shown below.</t>
<figure><artwork><![CDATA[
+----------+-------+-----------------------------+---------------+
| 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 |
+----------+-------+-----------------------------+---------------+
]]></artwork>
</figure>
</section>
<section title="Primary Bundle Protocol Version" anchor="sect-10.2"><t>
IANA is requested to add the following value to the Primary Bundle
Protocol Version registry in the Bundle Protocol Namespace.</t>
<figure><artwork><![CDATA[
+-------+-------------+---------------+
| Value | Description | Reference |
+-------+-------------+---------------+
| 7 | Assigned | RFC-to-be |
+-------+-------------+---------------+
]]></artwork>
</figure>
<t> Values 8-255 (rather than 7-255) are now Unassigned.</t>
</section>
<section title="Bundle Processing Control Flags" anchor="sect-10.3"><t>
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.</t>
<figure title="Bundle Processing Control Flags Registry">
<artwork><![CDATA[
+--------------------+----------------------------------+----------+
| 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 | |
+--------------------+----------------------------------+----------+
]]></artwork>
</figure>
</section>
<section title="Block Processing Control Flags" anchor="sect-10.4"><t>
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.</t>
<figure title="Block Processing Control Flags Registry">
<artwork><![CDATA[
+--------------------+----------------------------------+----------+
| 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 | |
+--------------------+----------------------------------+----------+
]]></artwork>
</figure>
</section>
<section title="Bundle Status Report Reason Codes" anchor="sect-10.5"><t>
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.</t>
<figure title="Bundle Status Report Reason Codes Registry">
<artwork><![CDATA[
+--------------------+----------------------------------+----------+ <td>6</td>
<td>2</td>
<td>Bundle Authentication Block</td>
<td><xref target="RFC6257"/></td>
</tr>
<tr>
| Bundle | Value | Description | Reference| <td>6</td>
<td>3</td>
<td>Payload Integrity Block</td>
<td><xref target="RFC6257"/></td>
</tr>
<tr>
| Protocol| | | | <td>6</td><td>4</td>
<td>Payload Confidentiality Block</td>
<td><xref target="RFC6257"/></td>
</tr>
<tr>
| Version | | | | <td>6</td>
<td>5</td>
<td>Previous-Hop Insertion Block</td>
<td><xref target="RFC6259"/></td>
</tr>
<tr>
| | | | | <td>7</td>
<td>6</td>
<td>Previous node (proximate sender)</td>
<td>[RFC9171]</td>
</tr>
<tr>
+--------------------+----------------------------------+----------+ <td>7</td>
<td>7</td>
<td>Bundle age (in milliseconds)</td>
<td>[RFC9171]</td>
</tr>
<tr>
| 6,7 | 0 | No additional information |[RFC5050],| <td>6</td>
<td>8</td>
<td>Metadata Extension Block</td>
<td><xref target="RFC6258"/></td>
</tr>
<tr>
| | | |RFC-to-be | <td>6</td>
<td>9</td>
<td>Extension Security Block</td>
<td><xref target="RFC6257"/></td>
</tr>
<tr>
| 6,7 | 1 | Lifetime expired |[RFC5050],| <td>7</td>
<td>10</td>
<td>Hop count (#prior xmit attempts)</td>
<td>[RFC9171]</td>
</tr>
<tr>
<td>7</td>
<td>11-191</td>
<td>Unassigned</td>
<td></td>
</tr>
<tr>
| | | |RFC-to-be | <td>6,7</td>
<td>192-255</td>
<td>Reserved for Private and/or Experimental Use</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr>
| 6,7 | 2 | Forwarded over unidirectional |[RFC5050],| </tbody>
</table>
</section>
<section anchor="sect-9.2" numbered="true" toc="default">
<name>Primary Bundle Protocol Version</name>
<t>
IANA has added the following value to the "Primary Bundle
Protocol Version" subregistry in the "Bundle Protocol" registry.</t>
<table align="left">
<name>"Primary Bundle Protocol Version" Registry</name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>7</td>
<td>Assigned</td>
<td>[RFC9171]</td>
</tr>
</tbody>
</table>
<t> Values 8-255 (rather than 7-255) are now Unassigned.</t>
</section>
<section anchor="sect-9.3" numbered="true" toc="default">
<name>Bundle Processing Control Flags</name>
<t>
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 <xref target="sect-4.2.3"/>, to the "Bundle Processin
g
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 preexist
ing values in the "Bundle Processing
Control Flags" registry, as shown below.</t>
<table align="left">
<name>"Bundle Processing Control Flags" Registry</name>
<thead>
<tr>
<th>Bundle Protocol Version</th>
<th>Bit Position (right to left)</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>6,7</td>
<td>0</td>
<td>Bundle is a fragment</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6,7</td>
<td>1</td>
<td>ADU is an administrative record</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6,7</td>
<td>2</td>
<td>Bundle must not be fragmented</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6</td>
<td>3</td>
<td>Custody transfer is requested</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
<td>6</td>
<td>4</td>
<td>Destination endpoint is a singleton</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
<td>6,7</td>
<td>5</td>
<td>Acknowledgement by application is requested</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>7</td>
<td>6</td>
<td>Status time requested in reports</td>
<td>[RFC9171]</td>
</tr><tr>
<td>6</td>
<td>7-8</td>
<td>Class of service: priority</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
<td>6</td>
<td>9-13</td>
<td>Class of service: reserved</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
<td>6,7</td>
<td>14</td>
<td>Request reporting of bundle reception</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6</td>
<td>15</td>
<td>Request reporting of custody acceptance</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
<td>6,7</td>
<td>16</td>
<td>Request reporting of bundle forwarding</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6,7</td>
<td>17</td>
<td>Request reporting of bundle delivery</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6,7</td>
<td>18</td>
<td>Request reporting of bundle deletion</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6,7</td>
<td>19</td>
<td>Reserved</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td>6,7</td>
<td>20</td>
<td>Reserved</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
<td></td>
<td>21-63</td>
<td>Unassigned</td>
<td></td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-9.4" numbered="true" toc="default">
<name>Block Processing Control Flags</name>
<t>
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 Proce
ssing
Control Flags" registry, as shown below.</t>
| | | link |RFC-to-be | <table align="left">
<name>"Block Processing Control Flags" Registry</name>
<thead>
<tr>
<th>Bundle Protocol Version</th>
<th><t>Bit Position (right to left)</t></th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
| 6,7 | 3 | Transmission canceled |[RFC5050],| <td>6,7</td>
<td>0</td>
<td>Block must be replicated in every fragment</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| | | |RFC-to-be | <td>6,7</td>
<td>1</td>
<td>Transmit status report if block can't be processed</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| 6,7 | 4 | Depleted storage |[RFC5050],| <td>6,7</td>
<td>2</td>
<td>Delete bundle if block can't be processed</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| | | |RFC-to-be | <td>6</td>
<td>3</td>
<td>Last block</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
| 6,7 | 5 | Destination endpoint ID |[RFC5050],| <td>6,7</td>
<td>4</td>
<td>Discard block if it can't be processed</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| | | unavailable |RFC-to-be | <td>6</td>
<td>5</td>
<td>Block was forwarded without being processed</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
| 6,7 | 6 | No known route to destination |[RFC5050],| <td>6</td>
<td>6</td>
<td>Block contains an EID-reference field</td>
<td><xref target="RFC5050"/></td>
</tr><tr>
| | | from here |RFC-to-be | <td></td>
<td>7-63</td>
<td>Unassigned</td>
<td></td>
</tr>
</tbody>
| 6,7 | 7 | No timely contact with next node |[RFC5050],| </table>
</section>
<section anchor="sect-9.5" numbered="true" toc="default">
<name>Bundle Status Report Reason Codes</name>
<t>
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 <xref target="sect-6.1.1"/>, to the "Bundle Status Re
port
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.</t>
<table align="left">
<name>"Bundle Status Report Reason Codes" Registry</name>
<thead>
<tr>
<th>Bundle Protocol Version</th>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>6,7</td>
<td>0</td>
<td>No additional information</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| | | on route |RFC-to-be | <td>6,7</td>
<td>1</td>
<td>Lifetime expired</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| 6,7 | 8 | Block unintelligible |[RFC5050],| <td>6,7</td>
<td>2</td>
<td>Forwarded over unidirectional link</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| | | |RFC-to-be | <td>6,7</td>
<td>3</td>
<td>Transmission canceled</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| 7 | 9 | Hop limit exceeded |RFC-to-be | <td>6,7</td>
<td>4</td>
<td>Depleted storage</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| 7 | 10 | Traffic pared |RFC-to-be | <td>6,7</td>
<td>5</td>
<td>Destination endpoint ID unavailable</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| 7 | 11 | Block unsupported |RFC-to-be | <td>6,7</td>
<td>6</td>
<td>No known route to destination from here</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| | 12-254 | Unassigned | | <td>6,7</td>
<td>7</td>
<td>No timely contact with next node on route</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| 6,7 | 255 | Reserved |[RFC6255],| <td>6,7</td>
<td>8</td>
<td>Block unintelligible</td>
<td><xref target="RFC5050"/> [RFC9171]</td>
</tr><tr>
| | | |RFC-to-be | <td>7</td>
<td>9</td>
<td>Hop limit exceeded</td>
<td>[RFC9171]</td>
</tr><tr>
+-------+-----------------------------------------------+----------+ <td>7</td>
<td>10</td>
<td>Traffic pared</td>
<td>[RFC9171]</td>
</tr><tr>
]]></artwork> <td>7</td>
</figure> <td>11</td>
</section> <td>Block unsupported</td>
<td>[RFC9171]</td>
</tr><tr>
<section title="Bundle Protocol URI scheme types" anchor="sect-10.6"><t> <td></td>
The Bundle Protocol has a URI scheme type field - an unsigned <td>17-254</td>
integer of indefinite length - for which IANA is requested to create <td>Unassigned</td>
and maintain a new "Bundle Protocol URI Scheme Type" registry in the <td></td>
Bundle Protocol Namespace. The "Bundle Protocol URI Scheme Type" </tr><tr>
registry governs an unsigned integer namespace. Initial values for
the Bundle Protocol URI Scheme Type registry are given below.</t>
<t> <td>6,7</td>
The registration policy for this registry is: Standards Action. The <td>255</td>
allocation should only be granted for a standards-track RFC approved <td>Reserved</td>
<td><xref target="RFC6255"/> [RFC9171]</td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-9.6" numbered="true" toc="default">
<name>Bundle Protocol URI Scheme Types</name>
<t>
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 th
e
"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.</t>
<t>
The registration policy for this registry is Standards Action <xref target="R
FC8126"/>. The
allocation should only be granted for a Standards Track RFC approved
by the IESG.</t> by the IESG.</t>
<t>
<t> The range of values is provided as unsigned integers.</t>
The value range is: unsigned integer.</t> <t>
<t>
Each assignment consists of a URI scheme type name and its Each assignment consists of a URI scheme type name and its
associated description, a reference to the document that defines the associated description, a reference to the document that defines the
URI scheme, and a reference to the document that defines the use of URI scheme, and a reference to the document that defines the use of
this URI scheme in BP endpoint IDs (including the CBOR this URI scheme in BP endpoint IDs (including the CBOR
representation of those endpoint IDs in transmitted bundles).</t> encoding of those endpoint IDs in transmitted bundles).</t>
<table align="left">
<figure title="Bundle Protocol URI Scheme Type Registry"> <name>"Bundle Protocol URI Scheme Types" Registry</name>
<artwork><![CDATA[ <thead>
<tr>
+---------+-------------+----------------+------------------+ <th>Value</th>
<th>Description</th>
| | | BP Utilization | URI Definition | <th>BP Utilization Reference</th>
<th>URI Definition Reference</th>
| Value | Description | Reference | Reference | </tr>
</thead>
+---------+-------------+----------------+------------------+ <tbody>
<tr>
| 0 | Reserved | n/a | | <td>0</td>
<td>Reserved</td>
| 1 | dtn | RFC-to-be | RFC-to-be | <td>n/a</td>
<td></td>
| 2 | ipn | RFC-to-be | [RFC6260], | </tr>
<tr>
| | | | RFC-to-be | <td>1</td>
<td>dtn</td>
| 3-254 | Unassigned | n/a | | <td>[RFC9171]</td>
<td>[RFC9171]</td>
|255-65535| reserved | n/a | | </tr>
<tr>
| >65535 | open for | n/a | | <td>2</td>
<td>ipn</td>
| | private use | n/a | | <td>[RFC9171]</td>
<td><xref target="RFC6260"/> [RFC9171]</td>
+---------+-------------+----------------+------------------+ </tr>
<tr>
]]></artwork> <td>3-254</td>
</figure> <td>Unassigned</td>
</section> <td>n/a</td>
<td></td>
<section title="URI scheme &quot;dtn&quot;" anchor="sect-10.7"><t> </tr>
In the Uniform Resource Identifier (URI) Schemes (uri-schemes) <tr>
registry, IANA is requested to update the registration of the URI <td>255-65535</td>
<td>Reserved</td>
<td>n/a</td>
<td></td>
</tr>
<tr>
<td>&gt;65535</td>
<td>Reserved for Private Use</td>
<td>n/a</td>
<td></td>
</tr>
</tbody>
</table>
</section>
<section anchor="sect-9.7" numbered="true" toc="default">
<name>dtn URI Scheme</name>
<t>
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:</t> scheme with the string "dtn" as the scheme name, as follows:</t>
<dl>
<dt>URI scheme name:</dt>
<dd>"dtn"</dd>
<dt>Status:</dt>
<dd>Permanent</dd>
<dt>Applications and/or protocols that use this URI scheme name:</dt>
<dd>The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).</dd>
<dt>Contact:</dt>
<dd><t><contact fullname="Scott Burleigh"/>
&lt;sburleig.sb@gmail.com&gt;</t>
</dd>
<dt>Change controller:</dt>
<dd>IETF (iesg@ietf.org)</dd>
<dt>Reference:</dt>
<dd>[RFC9171]</dd>
</dl>
<t> </section>
URI scheme name: "dtn"</t> <section anchor="sect-9.8" numbered="true" toc="default">
<name>ipn URI Scheme</name>
<t> <t>
Status: permanent</t> In the "Uniform Resource Identifier (URI) Schemes" (uri-schemes)
registry, IANA has updated the registration of the URI
<t>
Applications and/or protocols that use this URI scheme name: the
Delay-Tolerant Networking (DTN) Bundle Protocol (BP).</t>
<t>Contact:
<list>
<t>Scott Burleigh</t>
<t>Jet Propulsion Laboratory,</t>
<t>California Institute of Technology</t>
<t>scott.c.burleigh@jpl.nasa.gov</t>
<t>+1 (800) 393-3353</t>
</list>
</t>
<t>Change controller:
<list>
<t>IETF, iesg@ietf.org</t>
</list>
</t>
</section>
<section title="URI scheme &quot;ipn&quot;" anchor="sect-10.8"><t>
In the Uniform Resource Identifier (URI) Schemes (uri-schemes)
registry, IANA is requested to update the registration of the URI
scheme with the string "ipn" as the scheme name, originally scheme with the string "ipn" as the scheme name, originally
documented in RFC 6260 <xref target="RFC6260"/>, as follows.</t> documented in RFC 6260 <xref target="RFC6260" format="default"/>, as follows.
</t>
<t> <dl>
URI scheme name: "ipn"</t> <dt>URI scheme name:</dt>
<dd>"ipn"</dd>
<t> <dt>Status:</dt>
Status: permanent</t> <dd>Permanent</dd>
<dt>Applications and/or protocols that use this URI scheme name:</dt>
<t> <dd>The Delay-Tolerant Networking (DTN) Bundle Protocol (BP).</dd>
Applications and/or protocols that use this URI scheme name: the <dt>Contact:</dt>
Delay-Tolerant Networking (DTN) Bundle Protocol (BP).</t> <dd><t><contact fullname="Scott Burleigh"/>
&lt;sburleig.sb@gmail.com&gt;</t>
<t>Contact: </dd>
<dt>Change controller:</dt>
<list> <dd>IETF (iesg@ietf.org)</dd>
<t>Scott Burleigh</t> <dt>Reference:</dt>
<dd>[RFC9171]</dd>
<t>Jet Propulsion Laboratory,</t> </dl>
</section>
<t>California Institute of Technology</t> </section>
</middle>
<t>scott.c.burleigh@jpl.nasa.gov</t> <back>
<t>+1 (800) 393-3353</t>
</list>
</t>
<t>Change controller:
<list>
<t>IETF, iesg@ietf.org</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.ietf-dtn-bpsec;
<!-- <reference><front> -->
<!--
draft-ietf-dtn-bpbis-31-manual.txt(2665): Warning: Failed parsing a reference
.
Are all elements separated by commas (not periods, not just spaces)?:
[CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4,
International Telecommunications Union, October 1996.
-->
<!-- </front> -->
<!-- </reference> -->
&RFC2119;
&RFC4960;
&RFC5234;
&RFC8174;
&RFC8949;
<!-- <reference><front> -->
<!--
draft-ietf-dtn-bpbis-31-manual.txt(2683): Warning: Failed parsing a reference
.
Are all elements separated by commas (not periods, not just spaces)?:
[SABR] "Schedule-Aware Bundle Routing", CCSDS Recommended Standard
734.3-B-1, Consultative Committee for Space Data Systems, July 2019.
-->
<!-- </front> -->
<!-- </reference> -->
&I-D.ietf-dtn-tcpclv4;
<reference anchor="URI"><front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
</author>
<author initials="R." surname="Fielding" fullname="R. Fielding">
</author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
</author>
<date month="January" year="2005"/>
</front>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="STD" value="66"/>
</reference>
<reference anchor="URIREG"><front>
<title>Guidelines and Registration Procedures for URI Schemes</title>
<author initials="D." surname="Thaler" fullname="D. Thaler">
</author>
<author initials="T." surname="Hansen" fullname="T. Hansen">
</author>
<author initials="T." surname="Hardie" fullname="T. Hardie">
</author>
<date month="June" year="2015"/>
</front>
<seriesInfo name="RFC" value="7595"/>
<seriesInfo name="BCP" value="35"/>
</reference>
</references>
<references title="Informative References">
<!-- <reference><front> -->
<!--
draft-ietf-dtn-bpbis-31-manual.txt(2700): Warning: Failed parsing a reference
.
Are all elements separated by commas (not periods, not just spaces)?:
[ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC
4838, April 2007.
-->
<!-- </front> -->
<!-- </reference> -->
&I-D.ietf-dtn-bibect;
&RFC3987;
&RFC5050;
&RFC6255;
&RFC6257;
&RFC6258;
&RFC6259;
&RFC6260;
&RFC7143;
<!-- <reference><front> -->
<!--
draft-ietf-dtn-bpbis-31-manual.txt(2731): Warning: Failed parsing a reference
.
Are all elements separated by commas (not periods, not just spaces)?:
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", SIGCOMM 2003.
-->
<!-- </front> -->
<!-- </reference> -->
</references>
<section title="Acknowledgments" anchor="sect-12"><t>
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.</t>
<t>
This document was prepared using 2-Word-v2.0.template.dot.</t>
</section>
<section title="Significant Changes from RFC 5050" anchor="sect-13"><t>
Points on which this draft significantly differs from RFC 5050
include the following:
<list style="symbols">
<t>Clarify the difference between transmission and forwarding.</t>
<t>Migrate custody transfer to the bundle-in-bundle encapsulation
specification <xref target="I-D.ietf-dtn-bibect"/>.</t>
<t>Introduce the concept of "node ID" as functionally distinct from <displayreference target="RFC3986" to="URI"/>
endpoint ID, while having the same syntax.</t> <displayreference target="RFC4838" to="ARCH"/>
<displayreference target="RFC7595" to="URIREG"/>
<displayreference target="RFC9172" to="BPSEC"/>
<displayreference target="RFC9174" to="TCPCL"/>
<displayreference target="I-D.ietf-dtn-bibect" to="BIBE"/>
<t>Restructure primary block, making it immutable. Add optional <references>
CRC.</t> <name>References</name>
<references>
<name>Normative References</name>
<t>Add optional CRCs to non-primary blocks.</t> <!-- draft-ietf-dtn-bpsec ([BPSEC] per orig.; RFC 9172) -->
<reference anchor='RFC9172' target="https://www.rfc-editor.org/info/rfc9172">
<front>
<title>Bundle Protocol Security (BPSec)</title>
<author initials='E' surname='Birrane, III' fullname='Edward J. Birrane, I
II'>
<organization />
</author>
<author initials='K' surname='McKeever' fullname='Kenneth McKeever'>
<organization />
</author>
<date month='January' year='2022' />
</front>
<seriesInfo name="RFC" value="9172"/>
<seriesInfo name="DOI" value="10.17487/RFC9172"/>
</reference>
<t>Add block ID number to canonical block format (to support <reference anchor="CRC16" target="https://www.itu.int/rec/T-REC-X.25-199610-I/">
BPsec).</t> <front>
<title>X.25: Interface between Data Terminal Equipment (DTE) and Data Circuit
-terminating Equipment (DCE) for terminals operating in the packet mode and conn
ected to public data networks by dedicated circuit</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="October" year="1996"/>
</front>
<seriesInfo name="ITU-T Recommendation" value="X.25"/>
<refcontent>p. 9, Section 2.2.7.4</refcontent>
</reference>
<t>Add definition of bundle age extension block.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4960.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8949.xml"/>
<t>Add definition of previous node extension block.</t> <reference anchor="SABR" target="https://public.ccsds.org/Pubs/734x3b1.pdf">
<front>
<title>Schedule-Aware Bundle Routing</title>
<author>
<organization>Consultative Committee for Space Data Systems</organizat
ion>
</author>
<date month="July" year="2019"/>
</front>
<seriesInfo name="CCSDS Recommended Standard" value="734.3-B-1"/>
</reference>
<t>Add definition of hop count extension block.</t> <!-- draft-ietf-dtn-tcpclv4 ([TCPCL] per orig.; RFC 9174) -->
<reference anchor='RFC9174' target="https://www.rfc-editor.org/info/rfc9174">
<front>
<title>Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4<
/title>
<author initials='B' surname='Sipos' fullname='Brian Sipos'>
<organization />
</author>
<author initials='M' surname='Demmer' fullname='Michael Demmer'>
<organization />
</author>
<author initials='J' surname='Ott' fullname='Jörg Ott'>
<organization />
</author>
<author initials='S' surname='Perreault' fullname='Simon Perreault'>
<organization />
</author>
<date month='January' year='2022' />
</front>
<seriesInfo name="RFC" value="9174"/>
<seriesInfo name="DOI" value="10.17487/RFC9174"/>
</reference>
<t>Remove Quality of Service markings.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7595.xml"/>
</references>
<references>
<name>Informative References</name>
<t>Change from SDNVs to CBOR representation.</t> <!-- draft-ietf-dtn-bibect ([BIBE]; Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-dtn-bibect.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3987.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5050.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6255.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6257.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6258.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6259.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6260.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7143.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<t>Add lifetime overrides.</t> <reference anchor="SIGC" target="https://dl.acm.org/doi/10.1145/863955.863960">
<front>
<title>A Delay-Tolerant Network Architecture for Challenged Internets</t
itle>
<author initials="K" surname="Fall" fullname="Kevin Fall">
<organization></organization>
</author>
<date month="August" year="2003"/>
</front>
<seriesInfo name="DOI" value="10.1145/863955.863960"/>
<refcontent>SIGCOMM 2003</refcontent>
</reference>
<t>Time values are denominated in milliseconds, not seconds.</t> </references>
</list> </references>
<section anchor="app-a" numbered="true" toc="default">
<name>Significant Changes from RFC 5050</name>
<t>
This document makes the following significant changes from RFC 5050:
</t> </t>
<ul spacing="normal">
</section> <li>Clarifies the difference between transmission and forwarding.</li>
<li>Migrates custody transfer to the bundle-in-bundle encapsulation
<section title="For More Information" anchor="sect-a"><t> specification <xref target="I-D.ietf-dtn-bibect" format="default"/>.</
Copyright (c) 2021 IETF Trust and the persons identified as authors li>
of the code. All rights reserved.</t> <li>Introduces the concept of "node ID" as functionally distinct from
endpoint ID, while having the same syntax.</li>
<t> <li>Restructures primary block, making it immutable. Adds optional
Redistribution and use in source and binary forms, with or without CRC.</li>
modification, is permitted pursuant to, and subject to the license <li>Adds optional CRCs to non-primary blocks.</li>
terms contained in, the Simplified BSD License set forth in Section <li>Adds block ID number to canonical block format (to support
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents BPSec).</li>
(<eref target="http://trustee.ietf.org/license-info"/>).</t> <li>Adds definition of Bundle Age extension block.</li>
<li>Adds definition of Previous Node extension block.</li>
</section> <li>Adds definition of Hop Count extension block.</li>
<li>Removes Quality of Service markings.</li>
<section title="CDDL expression" anchor="sect-b"><t> <li>Changes from Self-Delimiting Numeric Values (SDNVs) to CBOR encoding
.</li>
<li>Adds lifetime overrides.</li>
<li>Clarifies that time values are denominated in milliseconds, not seco
nds.</li>
</ul>
</section>
<section anchor="app-c" numbered="true" toc="default">
<name>CDDL Expression</name>
<t>
For informational purposes, Carsten Bormann and Brian Sipos have For informational purposes, Carsten Bormann and Brian Sipos have
kindly provided an expression of the Bundle Protocol specification kindly provided an expression of the Bundle Protocol specification
in the Concise Data Definition Language (CDDL). That CDDL in the Concise Data Definition Language (CDDL). That CDDL
expression is presented below. Note that wherever the CDDL expression is presented below. Note that wherever the CDDL
expression is in disagreement with the textual representation of the expression is in disagreement with the textual representation of the
BP specification presented in the earlier sections of this document, BP specification presented in the earlier sections of this document,
the textual representation rules.</t> the textual representation rules.</t>
<sourcecode type="cddl"><![CDATA[
<figure><artwork><![CDATA[
bpv7_start = bundle / #6.55799(bundle) bpv7_start = bundle / #6.55799(bundle)
; Times before 2000 are invalid ; Times before 2000 are invalid
dtn-time = uint dtn-time = uint
; CRC enumerated type ; CRC enumerated type
crc-type = &( crc-type = &(
skipping to change at line 3304 skipping to change at line 3009
), ),
? crc-value, ? crc-value,
] ]
bundle-control-flags = uint .bits bundleflagbits bundle-control-flags = uint .bits bundleflagbits
bundleflagbits = &( bundleflagbits = &(
reserved: 21,
reserved: 20, reserved: 20,
reserved: 19, reserved: 19,
bundle-deletion-status-reports-are-requested: 18, bundle-deletion-status-reports-are-requested: 18,
bundle-delivery-status-reports-are-requested: 17, bundle-delivery-status-reports-are-requested: 17,
bundle-forwarding-status-reports-are-requested: 16, bundle-forwarding-status-reports-are-requested: 16,
skipping to change at line 3362 skipping to change at line 3065
canonical-block-structure = [ canonical-block-structure = [
block-type-code: uint, block-type-code: uint,
block-number: uint, block-number: uint,
block-control-flags, block-control-flags,
crc-type, crc-type,
; Each block type defines the content within the bytestring ; Each block type defines the content within the byte string
block-type-specific-data, block-type-specific-data,
? crc-value ? crc-value
] ]
block-control-flags = uint .bits blockflagbits block-control-flags = uint .bits blockflagbits
blockflagbits = &( blockflagbits = &(
skipping to change at line 3386 skipping to change at line 3089
reserved: 6, reserved: 6,
reserved: 5, reserved: 5,
block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4, block-must-be-removed-from-bundle-if-it-cannot-be-processed: 4,
reserved: 3, reserved: 3,
bundle-must-be-deleted-if-block-cannot-be-processed: 2, bundle-must-be-deleted-if-block-cannot-be-processed: 2,
status-report-must-be-transmitted-if-block-cannot-be-processed: 1, status-report-must-be-transmitted-if-block-cannot-be-processed:
1,
block-must-be-replicated-in-every-fragment: 0 block-must-be-replicated-in-every-fragment: 0
) )
block-type-specific-data = bstr / #6.24(bstr) block-type-specific-data = bstr / #6.24(bstr)
; Actual CBOR data embedded in a bytestring, with optional tag to ; Actual CBOR data embedded in a byte string, with optional tag to
indicate so. indicate so.
; Additional plain bstr allows ciphertext data. ; Additional plain bstr allows ciphertext data.
embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) / embedded-cbor<Item> = (bstr .cbor Item) / #6.24(bstr .cbor Item) /
bstr bstr
; Extension block type, which does not specialize other than the ; Extension block type, which does not specialize other than the
code/number code/number
extension-block = $extension-block .within canonical-block-structure extension-block =
$extension-block .within canonical-block-structure
; Generic shared structure of all non-primary blocks ; Generic shared structure of all non-primary blocks
extension-block-use<CodeValue, BlockData> = [ extension-block-use<CodeValue, BlockData> = [
block-type-code: CodeValue, block-type-code: CodeValue,
block-number: (uint .gt 1), block-number: (uint .gt 1),
block-control-flags, block-control-flags,
skipping to change at line 3446 skipping to change at line 3151
block-control-flags, block-control-flags,
crc-type, crc-type,
$payload-block-data, $payload-block-data,
? crc-value ? crc-value
] ]
; Arbitrary payload data, including non-CBOR bytestring ; Arbitrary payload data, including non-CBOR byte string
$payload-block-data /= block-type-specific-data $payload-block-data /= block-type-specific-data
; Administrative record as a payload data specialization ; Administrative record as a payload data specialization
$payload-block-data /= embedded-cbor<admin-record> $payload-block-data /= embedded-cbor<admin-record>
admin-record = $admin-record .within admin-record-structure admin-record = $admin-record .within admin-record-structure
admin-record-structure = [ admin-record-structure = [
skipping to change at line 3537 skipping to change at line 3242
extension-block-use<10, embedded-cbor<ext-data-hop-count>> extension-block-use<10, embedded-cbor<ext-data-hop-count>>
ext-data-hop-count = [ ext-data-hop-count = [
hop-limit: uint, hop-limit: uint,
hop-count: uint hop-count: uint
] ]
]]></sourcecode>
</section>
]]></artwork> <section anchor="acks-section" numbered="false" toc="default">
</figure> <name>Acknowledgments</name>
</section> <t>
This work is freely adapted from RFC 5050, which was an effort of
</back> the Delay-Tolerant Networking Research Group. The following DTNRG
participants contributed significant technical material and/or
</rfc> inputs to that document: <contact fullname="Dr. Vinton Cerf"/> of Google;
<contact fullname="Scott Burleigh"/>, <contact fullname="Adrian Hooke"/>, and
<contact fullname="Leigh Torgerson"/> of the Jet Propulsion Laboratory;
<contact fullname="Michael Demmer"/> of the University of California at Berke
ley;
<contact fullname="Robert Durst"/>, <contact fullname="Keith Scott"/>, and
<contact fullname="Susan Symington"/> of The MITRE Corporation;
<contact fullname="Kevin Fall"/> of Carnegie Mellon University;
<contact fullname="Stephen Farrell"/> of Trinity College Dublin;
<contact fullname="Howard Weiss"/> and <contact fullname="Peter Lovell"/> of
SPARTA, Inc.;
and <contact fullname="Manikantan Ramadas"/> of Ohio University.</t>
<t>Scott Burleigh would like to thank the Jet Propulsion Laboratory, Californ
ia Institute of Technology, for its generous and sustained support of this work.
</t>
</section>
</back>
</rfc>
 End of changes. 389 change blocks. 
2505 lines changed or deleted 2365 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/