Delay/Disruption Tolerant Networking D. V. G. Cerf
Internet-Draft Google Corporation
Intended status: Informational S. C. Burleigh
Expires: 8 January 2026 JHU Applied Physics Laboratory
R. C. Durst
The MITRE Corporation
D. K. Fall
Intel Research, Berkeley
D. K. L. Scott
The MITRE Corporation
L. Torgerson
Jet Propulsion Laboratory
H. S. Weiss
SPARTA, Inc.
July 2025
Delay-Tolerant Networking Architecture
draft-cerf-dtn-4838bis-00
Abstract
This document describes an architecture for delay-tolerant and
disruption-tolerant networks. It is an evolution of the architecture
originally designed for the Interplanetary Internet, a communication
system envisioned to provide Internet-like services across
interplanetary distances in support of deep space exploration. This
document describes an architecture that addresses a variety of
problems with internetworks having operational and performance
characteristics that make conventional (Internet-like) networking
approaches either unworkable or impractical. We define a overlay
protocol that interconnects multiple internets. The document
presents a motivation for the architecture, an architectural
overview, review of state management required for its operation, and
a discussion of application design issues. This document represents
the consensus of the IETF DTN working group and has been widely
reviewed by that group.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://edbirrane.github.io/4838bis/draft-cerf-dtn-4838bis.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-cerf-dtn-4838bis/.
Discussion of this document takes place on the Delay/Disruption
Tolerant Networking mailing list (mailto:dtn@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/dtn/. Subscribe
at https://www.ietf.org/mailman/listinfo/dtn/.
Source for this draft and an issue tracker can be found at
https://github.com/edbirrane/4838bis.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 January 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction
2. Conventions used in this document
3. Terminology
4. Providing the DTN Overlay Service
4.1. Quality of Service
4.1.1. Custody Transfer
4.1.2. Priority
4.1.3. Postal-Style Delivery Options
5. DTN Architecture
5.1. Virtual Message Switching Using Store-and-Forward Operation
5.2. Endpoint Identifiers (EIDs) and Registrations
5.3. URI Schemes
5.4. Late Binding
5.5. Primary Bundle Fields
5.6. Other Bundle Fields
5.7. Routing and Forwarding
5.7.1. Types of Contacts
5.8. Reliability and Custody Transfer
5.9. DTN Support for Proxies and Application Layer Gateways
5.10. Timestamps and Time Synchronization
5.11. Congestion and Flow Control at the Bundle Layer
5.12. Security
5.13. Administrative Records: Bundle Status Reports
5.14. State Management Considerations
5.14.1. Application Registration State
5.14.2. Bundle Routing and Forwarding State
5.14.3. Security-Related State
5.15. Policy and Configuration State
5.16. Application Structuring Issues
5.17. Convergence Layer Considerations for Use of Underlying
Protocols
6. Summary
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
This document describes an architecture for delay and disruption-
tolerant interoperable networking (DTN). The architecture embraces
the concepts of occasionally-connected networks that may suffer from
frequent partitions and that may encompass multiple divergent sets of
protocols or protocol families. The basis for this architecture lies
with that of the Interplanetary Internet, which focused primarily on
the issue of deep space communication in high-delay environments. We
expect the DTN architecture described here to be utilized in various
operational environments, including those subject to disruption and
disconnection and those with lengthy signal propagation latencies\;
the case of deep space is one specialized example of these and is
being pursued as a specialization of this architecture (See [IPN01]
and [SB03] for more details).
Other networks to which we believe this architecture applies include
sensor-based networks using scheduled intermittent connectivity,
terrestrial wireless networks that cannot ordinarily maintain end-to-
end connectivity, satellite networks with moderate delays and
periodic connectivity, and underwater acoustic networks with moderate
delays and frequent interruptions due to environmental factors. A
DTN tutorial [FW03], aimed at introducing DTN and the types of
networks for which it is designed, is available to introduce new
readers to the fundamental concepts and motivation. More technical
descriptions may be found in [KF03], [JFP04], [JDPF05], and [WJMF05].
Our motivation for developing an architecture for delay tolerant
networking stems from several factors. These factors are summarized
below\; much more detail on their rationale can be explored in
[SB03], [KF03], and [DFS02], and "Revisiting the Use of the IP
Protocol Stack in Deep Space" [SB01] further discusses the motivation
for the development of DTN.
Briefly, the existing Internet protocols do not work well for some
environments, due to some fundamental assumptions built into the
Internet architecture:
* that an end-to-end path between source and destination exists for
the duration of a communication session
* (for reliable communication) that end-to-end retransmission from
the data source based on timely and stable feedback from the data
receiver is an effective means for repairing errors
* that the rate of end-to-end data loss is relatively small
* that all routers and end stations support the TCP/IP protocols
* that packet switching is the most appropriate abstraction for
interoperability and performance
* that selecting a single route between sender and receiver is
sufficient for achieving acceptable communication performance
The DTN architecture is conceived to relax most of these assumptions,
based on a number of design principles that are summarized here (and
further discussed in [KF03]):
* Use variable-length (possibly long) messages (not streams or
limited-sized packets) as the communication abstraction to help
enhance the ability of the network to make good scheduling/path
selection decisions when possible.
* Use a naming syntax that supports a wide range of naming and
addressing conventions to enhance interoperability.
* Use storage within the network to support store-and-forward
operation over multiple paths and over potentially long timescales
(i.e., to support operation in environments where no end-to-end
paths may ever exist)\; do not require retransmission from the
data source.
* Provide security mechanisms that protect the infrastructure from
unauthorized use by discarding traffic as quickly as possible and
secure data at rest as well as data in transit.
* Provide coarse-grained classes of service, flexible delivery
options, and a way to express the useful lifetime of data to allow
the network to better deliver data in serving the needs of
applications.
As such, the intent of the architecture is to enable deployment of a
Solar System-wide network characterized by the scope of automation
that was developed for the Internet, enabling comparable power and
scalability.
To this end we define a new end-to-end protocol stack layer which we
term "bundle layer". We propose a protocol, named Bundle Protocol
(BP) [RFC9171], that functions at the bundle layer. The bundle layer
forms a delay- and disruption-tolerant overlay that interconnects
networks that can ordinarily sustain continuous end-to-end
connectivity and brief round-trip times, employing persistent storage
to help combat network interruption. For interoperability, it uses a
flexible naming scheme (based on Uniform Resource Identifiers
[RFC3986]) capable of encapsulating different naming and addressing
schemes in the same overall naming syntax. DTN also includes a
number of diagnostic and management features and has a security
model, optionally enabled, aimed at protecting infrastructure from
unauthorized use.
The bundle layer provides functionality similar to the internet layer
of interconnected gateways described in the original ARPANET/Internet
designs [CK74]. It differs from ARPANET gateways, however, in that
it is layer-agnostic and is focused on message forwarding rather than
packet switching. However, both architectures generally provide
interoperability between underlying protocols specific to one
environment and those protocols specific to another, and both provide
a store-and-forward forwarding service (with the bundle layer
employing persistent storage for its store and forward function).
In a sense, the DTN architecture provides a common method for
interconnecting heterogeneous gateways or proxies that employ store-
and-forward message routing to overcome communication disruptions.
The architecture's delay tolerant forwarding is comparable to the
procedures of electronic mail, but with enhanced naming, routing, and
security capabilities. Nodes unable to support the full capabilities
required by this architecture may be supported by application-layer
proxies acting as DTN applications.
Separately, but also noteworthy, the DTN architecture can help to
"flatten" the protocol stack. The Bundle Protocol's scope of
operations can be amplified by the insertion of additional "extension
blocks" (such as the Block Integrity Block and Block Confidentiality
Block defined for BP security {BPSEC}) in the headers of BP protocol
data units and by the definition of administrative records (e.g.,
bundle status reports) that enable BP itself to accomplish network
management functions. These features enable DTN network stack
functionality to be augmented easily without the insertion of
additional protocol layers.
Note that the use of the bundle layer is guided not only by its own
design principles but also by application design principles:
* Applications should minimize the number of round-trip exchanges.
* Applications should cope with restarts after failure while network
transactions remain pending.
* Applications should inform the network of the useful life and
relative importance of data to be delivered.
These issues are discussed in further detail in Section 5.16.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Terminology
The following terms are used in the context of DTN in this document:
Bundle: A bundle is a protocol data unit of the Bundle Protocol *BP),
so named because negotiation of the parameters of a data exchange may
be impractical in a delay-tolerant network: it is often better
practice to "bundle" with a unit of application data all metadata
that might be needed in order to make the data immediately usable
when delivered to the application. Each bundle comprises a sequence
of two or more "blocks" of protocol data, which serve various
purposes.
Block: A Bundle Protocol block is one of the protocol data structures
that together constitute a well-formed bundle.
Application Data Unit: An application data unit (ADU) is the unit of
data whose conveyance to the bundle's destination is the purpose for
the issuance of some bundle .
Bundle payload: A bundle payload (or simply "payload") is the content
of the bundle's payload block.
Bundle node: A bundle node is any entity that can send and/or receive
bundles.
Bundle Protocol Agent: The Bundle Protocol Agent (BPA) of a node is
that component of a bundle node that offers BP services to
applications and executes the procedures of the Bundle Protocol.
Convergence-layer adapter: A convergence-layer adapter (CLA) is a
node component that sends and receives bundles on behalf of the BPA,
utilizing the services of some "integrated" protocol stack that is
supported in one of the networks within which the node is
functionally located. The topmost layer of such a stack is termed
the "convergence layer".
Administrative record: A BP administrative record is an ADU that is
exchanged between nodes for some BP administrative purpose. The only
administrative record defined in this document is the status report,
discussed later.
Bundle endpoint: A bundle endpoint (or simply "endpoint") is a set of
zero or more bundle nodes that all identify themselves for BP
purposes by some common identifier, called a "bundle endpoint ID"
(or, in this document, simply "endpoint ID").
Registration: A registration is the state machine characterizing a
given node's membership in a given endpoint.
Delivery: A bundle is considered to have been delivered at a node
subject to a registration as soon as the ADU that is the payload of
the bundle, together with any relevant metadata (an implementation
matter), has been presented to an application in a manner consistent
with the state of that registration.
Forwarding: To forward a bundle to a node is to invoke the services
of one or more CLAs in a sustained effort to cause a copy of the
bundle to be received by that node.
4. Providing the DTN Overlay Service
Earlier sections summarized the motivation for the DTN architecture
and identified the design principles that guide its definition. This
section describes the communication service that users can expect
from the DTN-based network.
A DTN-enabled application sends messages of arbitrary length, here
termed Application Data Units or ADUs [CT90], the delivery of which
is necessarily constrained by the nature of the network. ADUs may
not always be received in the order in which they were transmitted.
Multiple parts of an ADU might arrive at the destination at different
times.
ADUs are encapsulated by the bundle layer within protocol data units
called "bundles", which are forwarded by DTN "nodes."
A DTN node (or simply "node" in this document) is an engine for
sending and receiving bundles -- an implementation of the bundle
protocol. Applications utilize DTN nodes to send or receive ADUs
carried in bundles\; applications also use DTN nodes when acting as
report-to destinations for diagnostic information carried in bundles.
Nodes may be members of groups called "DTN endpoints"\; that is, a
DTN endpoint is a set of DTN nodes. A bundle is considered to have
been successfully delivered to a DTN endpoint when some minimum
subset of the nodes in the endpoint has received the bundle without
error. This subset is called the "minimum reception group" (MRG) of
the endpoint. The MRG of an endpoint may contain one node (unicast),
any one of the nodes in a group of nodes (anycast), or all nodes in a
group of nodes (multicast). A single node may be contained in the
MRGs of multiple endpoints.
While a bundle protocol endpoint is simply a set of DTN nodes, a
given endpoint may be defined to contain zero node (the "null
endpoint"), exactly 1 node (a "singleton endpoint", or N (where 0 <=
N) nodes (enabling multicast endpoints).
Each bundle contains an originating timestamp, a useful life
indicator ("time to live"), and a payload length. This information
provides bundle-layer routing with a priori knowledge of the size and
performance requirements of requested data transfers. When there is
a significant amount of queuing that can occur in the network (as is
the case in the DTN version of store-and-forward), the advantage
provided by knowing this information may be significant for making
scheduling and path selection decisions [JFP04]. An alternative
abstraction (i.e., of stream-based delivery based on packets) would
make such scheduling much more difficult. Although packets provide
some of the same benefits as bundles, larger aggregates provide a way
for the network to apply scheduling and buffer management to units of
data that are more useful to applications.
While IP networks are based on "store-and-forward" operation, there
is an assumption that the "storing" will not persist for more than a
modest amount of time, on the order of the queuing and transmission
delay. In contrast, the DTN architecture does not expect that
network links are always available or reliable, and instead expects
that nodes may need to store bundles for minutes, hours, or days. We
anticipate that most DTN nodes will use some form of persistent
storage for this purpose -- disk, flash memory, etc. -- and that
stored bundles will survive system restarts.
4.1. Quality of Service
Postal Service provides a reasonable metaphor for the Quality of
Service (QoS) parameters that might be applied in the DTN
architecture. Traffic is generally not interactive and is often one-
way. There are generally no strong guarantees of timely delivery,
yet there are some forms of reliability, priority, and security.
However, in DTN the values of bundles' QoS parameters are subject to
change as the bundles traverse the network. They are determined at
the bundle forwarding nodes based on policy (as established by node
administration) and on the immutable features of bundles such as
source and/or destination.
While QoS parameters are thus not addressed in the design of the
bundle protocol itself, several principles of QoS determination that
may apply to DTN have been identified.
4.1.1. Custody Transfer
"Custody Transfer" is an architectural concept first articulated in
the course of designing the CCSDS File Delivery Protocol. The
concept is that the environments addressed by DTN are so different
from terrestrial internetworking as to motivate a relaxation of the
End-to-End Argument that governs the Internet protocols.
Retransmission of lost bundle data from the source DTN node may take
so much time (due to lengthy signal propagation latencies and
punctuated connectivity) that delivery prior to time-to-live
expiration will simply fail\; retransmission instead from the node
that most recently forwarded the lost bundle can sharply reduce
delivery latency. This principle -- the advance from forwarding node
to forwarding node, along the end-to-end path, of lost data recovery
functionality -- is termed "custody transfer."
Custody transfer in DTN is typically accomplished not by means of a
dedicated protocol but rather by the use of reliable protocols in the
underlying network(s) on which the bundle protocol overlay is hosted.
The selection and invocation of these underlying protocol
capabilities is a key element in DTN QoS provisioning.
The DTN architecture is well suited to supporting _relative_ measures
of priority (low, medium, high), similar to Postal Service classes
that address customers' sense of ADU delivery urgency: * Bulk - Bulk
bundles are shipped on a "least effort" basis. No bundles of this
class will be shipped until all bundles of other classes bound for
the same destination and originating from the same source have been
shipped. * Normal - Normal-class bundles are shipped prior to any
bulk-class bundles and are otherwise the same as bulk bundles. *
Expedited - Expedited bundles, in general, are shipped prior to
bundles of other classes and are otherwise the same.
The combination of useful life limit (as aserted by the application)
and policy as applied at DTN nodes can be used to determine how
messages are forwarded and which routing algorithms are in use,
thereby affecting the overall likelihood and timeliness of ADU
delivery.
In this context, the applicable priority class of a bundle might have
effect only in relation to the forwarding of other bundles from the
same source and/or the same destination. This means that a high
priority bundle from one source might not be delivered sooner (or
with some other superior quality of service) than a medium priority
bundle from a different source. It is likely, though, that a high
priority bundle from one source to one destination will be handled in
preference to a lower priority bundle sent from the same source and
to the same destination.
Depending on a particular DTN node's forwarding/scheduling policy,
priority may or may not be enforced across different sources. That
is, in some DTN nodes, expedited bundles might always be sent prior
to any bulk bundles, irrespective of source. Many variations are
possible.
4.1.3. Postal-Style Delivery Options
Continuing with the postal analogy, the DTN architecture supports
several delivery options that may be selected by an application when
it requests the transmission of an ADU.
We have identified five delivery options. An application sending an
ADU (the "subject ADU") may request any combination of the following
options for the bundle issued in response to the application's
request to send the subject ADU:
* Custody Transfer Requested - requests that the bundle be forwarded
with reliability enhanced by custody transfer as described above.
The bundle should be transmitted from one node to the next using
reliable underlying transport protocols (if available).
* Report When Bundle Delivered - requests a (single) Bundle Delivery
Status Report be generated when the subject ADU is delivered to
its intended recipient(s). This option is similar to the postal
"return-receipt" service.
* Report When Bundle Received - requests a Bundle Reception Status
Report be generated each time the bundle arrives at a DTN node.
This is designed primarily for diagnostic purposes.
* Report When Bundle Forwarded - requests a Bundle Forwarding Status
Report be generated each time the bundle departs a DTN node after
forwarding. This too is designed primarily for diagnostic
purposes.
* Report When Bundle Deleted - requests a Bundle Deletion Status
Report be generated if and when the bundle is deleted at a DTN
node. This is likewise designed primarily for diagnostic
purposes.
The first of these delivery options is intended for routine use by
applications. The last four are designed primarily for diagnostic
purposes and their use may be restricted or limited in environments
subject to congestion or attack.
If the security procedures defined in [RFC9172] are also enabled,
then three additional delivery options become available:
* Confidentiality Required - requires that some subset of the blocks
of the bundle be made secret from parties other than the sources
and destinations of those blocks.
* Authentication Required - requires that some subset of the blocks
of the bundle be cryptographically authenticated. See
Section Section 5.12 for more details.
* Error Detection Required - requires that any modification of some
subset of the blocks of the bundle be detectable by cryptographic
means.
5. DTN Architecture
This section presents a description of the major features of the
architecture resulting from design decisions as guided by the design
principles discussed above.
5.1. Virtual Message Switching Using Store-and-Forward Operation
Each bundle has a defined format comprising two or more "blocks" of
data. Each block may contain either application data or other
information used to deliver the containing bundle to its
destination(s). Blocks contain information typically found in the
header and payload portions of protocol data units in other
protocols.
Bundle sources and destinations are identified by variable-length
Endpoint Identifiers (EIDs, described below), which identify the
original sender and final destination(s) of bundles, respectively. A
bundle may also contain a "report-to" EID used when special
operations are requested to direct diagnostic output to an arbitrary
entity (e.g., other than the source).
An essential element of the bundle-based style of forwarding is that
bundles must have a place to wait in a queue until a communication
opportunity ("contact") is available. This highlights the following
assumptions:
1. that storage is available and well-distributed throughout the
network,
2. that storage is sufficiently persistent and robust to store
bundles until forwarding can occur, and
3. (implicitly) that this "store-and-forward" model is a better
choice than attempting to effect continuous connectivity or other
alternatives.
For a network to effectively support the DTN architecture, these
assumptions must be considered and must be found to hold. Even so,
the inclusion of long-term storage as a fundamental aspect of the DTN
architecture poses new problems, especially with respect to
congestion management and denial-of-service mitigation. Node storage
in essence represents an additional network resource that must be
managed and protected. Much of the research in DTN revolves around
exploring these issues. Congestion is discussed in Section 5.11\;
security mechanisms, including methods for DTN nodes to protect
themselves from handling unauthorized traffic from other nodes, are
discussed in [DTNSOV] and [RFC9172].
5.2. Endpoint Identifiers (EIDs) and Registrations
An Endpoint Identifier (EID) is a name, expressed using the general
syntax of URIs (see below), that identifies a DTN endpoint. Using
the specification for the URI scheme of an EID, a node is able to
determine the MRG of the DTN endpoint named by the EID.
Accordlingly, an EID may identify zero, 1, or multiple DTN nodes,
enabling multicast destination or "report-to" endpoints. Each node
is required to be a member of at least one endppoint in order to
receive bundles\; each node is required to be a member of at least
one "singleton" endpoint (that is, an endpoint that always has
exactly one member) in order to source bundles that can be
authenticated by the network.
When referring to a group of size greater than one, the delivery
semantics may be of either the anycast or multicast variety. For
anycast group delivery, a bundle is intended to be delivered to one
node among a group of potentially many nodes\; for multicast delivery
it is intended to be delivered to all nodes in the group, subject to
the normal DTN maximum useful lifetime semantics.
The assertion of a node's membership in an endpoint is called a
"registration" and in general is maintained persistently by a DTN
node. This allows node registration information to survive operating
system restarts.
Applications send ADUs destined for endpoints identified by EIDs, and
they may arrange for ADUs sent to a particular EID to be delivered to
them. Depending on the construction of the EID being used (see
below), there may be a provision for wildcarding some portion of an
EID, which is often useful for diagnostic and routing purposes.
The assertion of an application's desire to receive ADUs destined for
a particular EID is termed an "enrollment." Enrollments, too, may be
maintained persistently by a DTN node, an implementation matter\;
this would enable application enrollment information likewise to
survive application and operating system restarts.
An application's attempt to establish an enrollment is not guaranteed
to succeed. For example, an application could request enrollment in
the reception of ADUs carried by bundles destined for an Endpoint
identified by an EID that is uninterpretable or unavailable to the
DTN node servicing the request. Such requests are likely to fail.
5.3. URI Schemes
Each Endpoint ID is expressed syntactically as a Uniform Resource
Identifier (URI) [RFC3986]. The URI syntax has been designed as a
way to express names or addresses for a wide range of purposes, and
is therefore useful for constructing names for DTN endpoints.
In URI terminology, each URI begins with a scheme name. The scheme
name is an element of the set of globally-managed scheme names
maintained by IANA [ISCHEMES]. Lexically following the scheme name
in a URI, separated from it by a colon (":") character, is a series
of characters constrained by the syntax defined by the scheme. This
portion of the URI is called the scheme-specific part (SSP), and can
be quite general. (See, as one example, the URI scheme for SNMP
[RFC4088]). Note that scheme-specific syntactical and semantic
restrictions may be more constraining than the basic rules of
[RFC3986]. Section 3.1 of [RFC3986] provides guidance on the syntax
of scheme names.
The use of URIs to identify endpoints introduces a great deal of
flexibility in the structuring of EIDs. DTN EIDs might, for example,
be constructed based on DNS names, or might look like "expressions of
interest" or take on the forms of database-like queries as in a
directed diffusion-routed network [IGE00] or in intentional naming
[WSBL99]. Being the names of sets of nodes, EIDs are not required to
be related to routing or topological organization. Such a
relationship is not prohibited, however, and in some environments
using EIDs this way might be advantageous.
A single EID may refer to an endpoint containing more than one DTN
node, as suggested above. It is the responsibility of a DTN EID
scheme designer to define how to interpret the SSP of an EID so as to
determine whether it refers to a unicast, multicast, or anycast set
of nodes. See [ANY-MULTI-CAST] for more details.
URIs are constructed based on rules specified in [RFC3986], using the
US-ASCII character set. However, note this excerpt from
Section 1.2.1 of [RFC3986], on dealing with characters that cannot be
represented by US-ASCII: "Percent-encoded octets (Section 2.1) may be
used within a URI to represent characters outside the range of the
US-ASCII coded character set if this representation is allowed by the
scheme or by the protocol element in which the URI is referenced.
Such a definition should specify the character encoding used to map
those characters to octets prior to being percent-encoded for the
URI".
5.4. Late Binding
Binding means interpreting the SSP of an EID for the purpose of
carrying an associated message towards a destination. For example,
binding might require mapping an EID to a next-hop EID or to a lower-
layer address for transmission. "Late binding" means that the
binding of a bundle's destination to a particular set of destination
identifiers or addresses does not necessarily happen at the bundle
source. Because the destination EID is potentially re-interpreted at
each hop, the binding may occur at the source, during transit, or
possibly at the destination(s). This contrasts with the name-to-
address binding of Internet communications where a DNS lookup at the
source fixes the IP address of the destination node before data is
sent. Such a circumstance would be considered "early binding"
because the name-to-address translation is performed prior to data
being sent into the network.
In a frequently-disconnected network, late binding may be
advantageous because the transit time of a message may exceed the
validity time of a binding, making binding at the source invalid or
even impossible. Furthermore, the use of name-based routing with
late binding may reduce the amount of administrative (mapping)
information that must propagate through the network, and may also
limit the scope of mapping synchronization requirements to a local
topological neighborhood where changes are made.
5.5. Primary Bundle Fields
The bundles carried between and among DTN nodes obey a standard
bundle protocol specified in [RFC9171]. Here we provide an overview
of most of the fields carried in every bundle. The protocol is
designed with a mandatory primary block, a mandatory payload block
(which contains the ADU data itself), and a set of optional extension
blocks. Blocks may be cascaded in a way similar to extension headers
in IPv6. The following selected fields are all present in the
primary block, and therefore are present for every bundle:
* Creation Timestamp - a concatenation of the bundle's creation time
and a monotonically increasing sequence number such that the
creation timestamp is guaranteed to be unique for each ADU
originating from the same source. The creation timestamp is based
on the time-of-day at which an application requested that the ADU
be sent (not when the corresponding bundle is sent into the
network). DTN nodes are assumed to have a basic time
synchronization capability (see Section 5.10).
* Lifespan - the length of time, following bundle creation tim,
after which the bundle's ADU is no longer useful. The "expiration
time" of a bundle is the time computed as the sum of the bundle's
creation time and its lifespan. If a bundle is stored at a
network node (including the source's DTN node) when its expiration
time is reached, it may be discarded.
* Bundle Processing Flags - indicates the selected delivery options.
See Section 4.1.3.
* Source EID - EID of a singleton endpoint of which the bundle's
source (the first sender) is the sole member.
* Destination EID - EID of the destination (the final intended
recipient(s)).
* Report-To Endpoint ID - an EID identifying where bundle status
reports should be sent. This may or may not identify the same
endpoint as the Source EID.
5.6. Other Bundle Fields
The payload block indicates information about the contained payload
(e.g., its length) and the payload itself. In addition to the fields
found in the primary and payload blocks, each bundle may have fields
in additional blocks carried with each bundle. See [RFC9171] for
additional details.
5.7. Routing and Forwarding
The DTN architecture provides a framework for routing and forwarding
at the bundle layer for unicast, anycast, and multicast messages.
Because nodes in a DTN network might be interconnected using more
than one type of underlying network technology, a DTN network is
commonly described abstractly using a _multigraph_ (a graph where
vertices may be interconnected with more than one edge). Edges in
this graph are, in general, time-varying with respect to their delay
and capacity and directional because of the possibility of one-way
connectivity. When an edge has zero capacity, it is considered to
not be connected.
Because edges in a DTN graph may be characterized by significant
delay, it is important to distinguish where time is measured when
expressing an edge's capacity or delay. We adopt the convention of
expressing capacity and delay as functions of time where time is
measured at the point where data is inserted into a network edge.
For example, consider an edge having capacity C(t) and delay D(t) at
time t. If B bits are placed in this edge at time t, they completely
arrive by time t + D(t) + (1/C(t))_B. We assume C(t) and D(t) do not
change significantly during the interval [t, t+D(t)+(1/C(t))_B].
Because edges may vary between positive and zero capacity, it is
possible to describe a period of time (interval) during which the
capacity is strictly positive, and the delay and capacity can be
considered to be constant [AF03]. This period of time is called a
"contact". In addition, the product of the capacity and the
magnitude of the interval is known as a contact's "volume". If
contacts and their volumes are known ahead of time, intelligent
routing and forwarding decisions can be made (optimally for small
networks) [JFP04].
When delivery paths through a DTN graph are lossy or contact
intervals and volumes are not known precisely ahead of time, routing
computations become especially challenging.
5.7.1. Types of Contacts
Contacts typically fall into one of several categories, based largely
on the predictability of their performance characteristics and
whether some action is required to bring them into existence. To
date, the following major types of contacts have been defined:
Persistent Contacts Persistent contacts are always available (i.e.,
no connection-initiation action is required to instantiate a
persistent contact). An 'always-on' Internet connection such as a
DSL or Cable Modem connection would be a representative of this
class.
On-Demand Contacts On-Demand contacts require some action in order
to be instantiated but then function as persistent contacts until
terminated. A dial-up connection is an example of an On-Demand
contact (at least, from the viewpoint of the dialer\; it may be
viewed as an Opportunistic Contact, below, from the viewpoint of
the dial-up service provider).
Intermittent - Scheduled Contacts A scheduled contact is an
agreement to establish a contact at a particular time, for a
particular duration. An example of a scheduled contact is a link
with a low-earth orbiting satellite. A node's list of contacts
with the satellite can be constructed from the satellite's
schedule of view times, capacities, and latencies. Note that for
networks with substantial delays, the notion of the time at which
a contact is established is delay-dependent. For example, a
single scheduled contact between Earth and Mars would not begin at
the same instant in each location, but would instead be offset by
the (non-negligible) propagation delay.
Intermittent - Opportunistic Contacts Opportunistic contacts are not
scheduled but rather present themselves unexpectedly. For
example, an unscheduled aircraft flying overhead and beaconing,
advertising its availability for communication, would present an
opportunistic contact. Another type of opportunistic contact
might be via an infrared or Bluetooth communication link between a
personal digital assistant (PDA) and a kiosk in an airport
concourse. The opportunistic contact begins as the PDA is brought
near the kiosk, lasting an indeterminant amount of time (i.e.,
until the link is lost or terminated).
Intermittent - Predicted Contacts Predicted contacts are based on no
fixed schedule, but rather are predictions of likely contact times
and durations based on a history of previously observed contacts
or some other information. Given a great enough confidence in a
predicted contact, routes may be chosen based on this information.
This is an active research area, and a few approaches having been
proposed [LFC05].
5.8. Reliability and Custody Transfer
The most basic service provided by the bundle layer is
unacknowledged, prioritized (but not guaranteed) unicast message
delivery. The bundle protocol also supports two options for
enhancing delivery reliability: custody transfer (described earlier)
and application acknowledgment requests. Applications wishing to
implement their own end-to-end message reliability mechanisms may
respond to an application acknowledgment request in an application-
specific manner.
5.9. DTN Support for Proxies and Application Layer Gateways
One of the aims of DTN is to provide a common method for
interconnecting application layer gateways and proxies. In cases
where existing Internet applications can be made to tolerate lengthy
and highly variable round-trip times, local proxies can be
constructed to benefit from the existing communication capabilities
provided by DTN [S05], [T02]. Making such proxies compatible with
DTN reduces the burden on the proxy author by providing support for
routing and reliability, enabling existing IP-based applications to
operate unmodified over a DTN-based network.
When DTN is used to provide a form of tunnel encapsulation for other
protocols, it can be used in constructing overlay networks composed
of application layer gateways. The application acknowledgment
capability is designed for such circumstances. This provides a
common way for remote application layer gateways to signal the
success or failure of non-DTN protocol operations initiated as a
result of receiving DTN ADUs.
5.10. Timestamps and Time Synchronization
The DTN architecture depends on time synchronization among DTN nodes
(supported by external, non-DTN protocols) for three primary
purposes: bundle identification, routing with scheduled or predicted
contacts, and bundle expiration time computations.
Bundle identification and expiration are supported by placing a
creation timestamp and an explicit expiration field (expressed in
milliseconds after the source timestamp) in each bundle. The
origination timestamps on arriving bundles are made available to
consuming applications in ADUs they receive by the application
programming interface. Each bundle is tagged a timestamp unique to
the source node's EID. The EID and timestamp together uniquely
identify a bundle. Unique bundle identification is used for a number
of purposes, notably including bundle status reporting.
5.11. Congestion and Flow Control at the Bundle Layer
For the purposes of this document, we define "flow control" as a
means of assuring that the average rate at which a sending node
transmits data to a receiving node does not exceed the average rate
at which the receiving node is prepared to receive data from that
sender. (Note that this is a generalized notion of flow control,
rather than one that applies only to end-to-end communication.) We
define "congestion control" as a means of assuring that the aggregate
rate at which all traffic sources inject data into a network does not
exceed the maximum aggregate rate at which the network can deliver
data to destination nodes over time. If flow control is propagated
backward from congested nodes toward traffic sources, then the flow
control mechanism can be used as at least a partial solution to the
problem of congestion as well.
DTN flow control decisions must be made within the bundle layer
itself based on information about resources (in this case, primarily
persistent storage) available within the bundle node. When storage
resources become scarce, a DTN node has only limited freedom in
handling the situation. It can discard a bundle immediately upon
reception if reception resources are insufficient to accommodate that
bundle, possibly sending a bundle status report noting that the
bundle was discarded. If storage resources are available elsewhere
in the network, it may be able to make use of them in some way for
bundle storage.
In addition to the bundle layer mechanisms described above, a DTN
node may be able to avail itself of support from lower-layer
protocols in controlling its own resource utilization. For example,
a DTN node receiving a bundle using TCP/IP might intentionally slow
down its receiving rate by performing read operations less frequently
in order to reduce its offered load. This is possible because TCP
provides its own flow control, so reducing the application data
consumption rate could effectively implement a form of hop-by-hop
flow control. Unfortunately, it may also lead to head-of-line
blocking issues, depending on the nature of bundle multiplexing
within a TCP connection. A protocol with more relaxed ordering
constraints (e.g. SCTP [RFC2960] or QUIC [RFC9000]) might be
preferable in such circumstances.
Congestion control in DTN is an ongoing research topic.
5.12. Security
The possibility of severe resource scarcity in some delay-tolerant
networks dictates that some form of authentication and control over
access to the network itself is required in many circumstances. It
is not acceptable for an unauthorized user to flood the network with
traffic easily, possibly denying service to authorized users. In
many cases it is also not acceptable for unauthorized traffic to be
forwarded over certain network links at all. This is especially true
for exotic, mission-critical links. In light of these
considerations, several goals are established for the security
component of the DTN architecture:
* Promptly prevent unauthorized applications from having their data
carried through or stored in the DTN.
* Prevent unauthorized applications from asserting control over the
DTN infrastructure.
* Prevent otherwise authorized applications from sending bundles at
a rate or class of service for which they lack permission.
* Promptly discard bundles that are damaged or improperly modified
in transit.
* Promptly detect and de-authorize compromised entities.
Many existing authentication and access control protocols designed
for operation in low-delay, connected environments may not perform
well in DTNs. In particular, updating access control lists and
revoking ("blacklisting") credentials may be especially difficult.
Also, approaches that require frequent access to centralized servers
to complete an authentication or authorization transaction are not
attractive. The consequences of these difficulties include delays in
the onset of communication, delays in detecting and recovering from
system compromise, and delays in completing transactions due to
inappropriate access control or authentication settings.
To help satisfy these security requirements in light of the
challenges, the DTN architecture adopts a standard but optionally
deployed security architecture [RFC9172] that supports both integrity
checking (which, when key-based, provides authentication as well) and
confidentiality. These measures may be exercised at forwarding
points along the bundle's path ("hop-by-hop") and/or at the final
destination node. While end-to-end use of BPSEC provides
authentication for a principal such as a user (of which there may be
many), hop-by-hop integrity checking is intended to intercept bogus
data before its forwarding wastes the resources of the network.
In accordance with the goals listed above, DTN nodes discard traffic
as early as possible if authentication checks fail. This approach
meets the goals of removing unwanted traffic from being forwarded
over specific high-value links, but also has the associated benefit
of making denial-of-service attacks considerably harder to mount more
generally, as compared with conventional Internet routers. However,
the obvious cost for this capability is potentially larger
computation and credential storage overhead required at DTN nodes.
For more detailed information on DTN security provisions, refer to
[RFC9172].
5.13. Administrative Records: Bundle Status Reports
As noted earlier, the DTN architecture accommodates the transmission
and reception of administrative records, whose sources and
destinations are the bundle protocol agents themselves.
Administrative records correspond (approximately) to messages in the
ICMP protocol in IP [RFC792]. The source EID of an administrative
record is the administrative EID of the source node\; for EIDs formed
in the "ipn" URI scheme, this is the EID whose service number is
zero.
At this time, one class of useful administrative records has been
defined: "bundle status reports" (BSRs). Bundle status reports are
used to report status information or error conditions related to the
bundle layer. They are directed to the report-to EIDs of the bundles
to which they pertain, which might differ from the source EIDs. In
some cases, arrival of a single bundle or bundle fragment may elicit
multiple bundle status reports (e.g., in the case where a bundle is
replicated for multicast forwarding).
The following BSRs are currently defined (also see [RFC9171] for more
details):
* Bundle Reception - sent when a bundle tagged with the Report When
Bundle Received option arrives at a DTN node. Generation of this
message may be limited by local policy.
* Bundle Forwarded - sent when a bundle tagged with the Report When
Bundle Forwarded option departs from a DTN node after having been
forwarded. Generation of this message may be limited by local
policy.
* Bundle Deletion - sent from a DTN node when a bundle tagged with
the Report When Bundle Deleted is discarded. This can happen for
any of several reasons, including expiration. Generation of this
message may be limited by local policy.
* Bundle Delivery - sent from a final recipient's (destination) node
when a bundle tagged with the Report When Bundle Delivered option
is delivered. Generation of this message may be limited by local
policy.
Every bundle status report must reference a received bundle. For
this purpose, bundles are uniquely identified as discussed above.
5.14. State Management Considerations
An important aspect of any networking architecture is its management
of state. This section describes the state managed at the bundle
layer and discusses how it is established and removed.
5.14.1. Application Registration State
In long/variable delay environments, an asynchronous application
interface seems most appropriate. Such interfaces may include
methods for applications to register callback actions when certain
triggering events occur (e.g., when ADUs arrive). These
registrations create state information called application enrollment
state.
Application enrollment state is typically created by explicit request
of the application, and is removed by a separate explicit request,
but may also be removed by an application-specified timer (it is thus
"firm" state). In most cases, there must be a provision for
retaining this state across application and operating system
termination/restart conditions because a client/server bundle round-
trip time may exceed the requesting application's execution time (or
hosting system's uptime). In cases where applications are not
automatically restarted but application enrollment state remains
persistent, a method must be provided to indicate to the system what
action to perform when the triggering event occurs (e.g., restarting
some application, ignoring the event, etc.).
To initiate an enrollment and thereby establish application
enrollment state, an application specifies an Endpoint ID at which it
wishes to receive ADUs. This operation is somewhat analogous to the
bind() operation in the common sockets API.
5.14.2. Bundle Routing and Forwarding State
As with the Internet architecture, we distinguish between routing and
forwarding. Routing refers to the execution of a (possibly
distributed) algorithm for computing routing paths according to some
objective function (see [JFP04], for example). Forwarding refers to
the act of moving a bundle from one DTN node to another. Routing
makes use of routing state (the RIB, or routing information base,
which notionally includes a contact graph as described earlier),
while forwarding makes use of state that is derived from routing and
is maintained as forwarding state (the FIB, or forwarding information
base). The structure of the FIB and the rules for maintaining it are
implementation choices. In some DTNs, exchange of information used
to update state in the RIB may take place on network paths distinct
from those where exchange of application data takes place.
The maintenance of state in the RIB is dependent on the type of
routing algorithm being used. A routing algorithm may consider
requested priority class, and this information will tend to increase
the size of the RIB. The separation between FIB and RIB is not
required by this document, as these are implementation details to be
decided by system implementers. The choice of routing algorithms
remains an active research topic.
Bundles may occupy queues in nodes for a considerable amount of time.
For unicast or anycast delivery, the amount of time is likely to be
the interval between when a bundle arrives at a node and when it can
be forwarded to its next hop. For multicast delivery of bundles,
this could be significantly longer, up to a bundle's expiration time.
5.14.3. Security-Related State
The DTN security approach described in [RFC9172], when used, requires
maintenance of state in all DTN nodes that use it. All such nodes
are required to store their own private information (including their
own policy and authentication material) and a block of information
used to verify credentials. Furthermore, in most cases, DTN nodes
will cache some public information (and possibly the credentials) of
their next-hop (bundle) neighbors. The cached information items may
have expiration times, in which case the timely delivery of new
security state information before current information expires is a
critical responsibility of network management.
In addition, access control may be used in a DTN by one or more
mechanisms such as capabilities or access control lists (ACLs). ACLs
would represent another block of state present in any node that
wishes to enforce security policy. ACLs are typically initialized at
node configuration time and may be updated dynamically by DTN bundles
or by some out of band technique. Capabilities or credentials may be
revoked, requiring the maintenance of a revocation list ("black
list", another form of state) to check for invalid authentication
material that has already been distributed.
5.15. Policy and Configuration State
DTN nodes will contain some amount of configuration and policy
information. Such information may alter the behavior of bundle
forwarding. Examples of policy state include the types of
cryptographic algorithms and access control procedures to use if DTN
security is employed, what types of convergence layer (see
Section 5.17) and routing protocols are in use, how bundles of
differing priority classes should be scheduled, where and for how
long bundles and other data are stored, what status reports may be
generated and at what rate, etc.
5.16. Application Structuring Issues
DTN bundle delivery is intended to operate in a delay-tolerant
fashion over a broad range of network types. This does not mean
there _must_ be large delays in the network\; it means there _may_ be
very significant delays (including extended periods of disconnection
between sender and intended recipient(s)). The DTN protocols are
delay tolerant, so applications using them must also be delay
tolerant in order to operate effectively in environments subject to
significant delay or disruption.
The communication primitives provided by the DTN architecture are
based on asynchronous, message-oriented communication which differs
from conversational request/response communication. In general,
applications should attempt to include enough information in an ADU
so that it may be treated as an independent unit of work by the
network and receiver(s). The goal is to minimize synchronous
interchanges between applications that are separated over a network
characterized by long and possibly highly variable delays. A single
file transfer request message, for example, might include
authentication information, file location information, and requested
file operation (thus "bundling" this information together).
Comparing this style of operation to a classic FTP transfer, one sees
that the bundled model can complete in one round trip, whereas an FTP
file "put" operation can take as many as eight round trips to get to
a point where file data can flow [DFS02].
Delay-tolerant applications must consider additional factors beyond
the conversational implications of long delay paths. For example, an
application may terminate (voluntarily or not) between the time it
sends a message and the time it expects a response. If this
possibility has been anticipated, the application can be "re-
instantiated" with state information saved in persistent storage.
This is an implementation issue, but also an application design
consideration.
Some consideration of delay-tolerant application design can result in
applications that work reasonably well in low-delay environments and
that do not suffer extraordinarily in high or highly-variable delay
environments.
5.17. Convergence Layer Considerations for Use of Underlying Protocols
Implementation experience with the DTN architecture has revealed an
important architectural consideration for DTN nodes [DBFJHP04]. Not
all underlying protocols in different protocol families provide the
same exact functionality, so some additional adaptation or
augmentation on a per-protocol or per-protocol-family basis may be
required. This adaptation is accomplished by "convergence-layer
adapters" which offer transmission functionality to the overlying
bundle protocol and utilize the transmission functionality offered by
the underlying protocol. The convergence layer adapters manage the
protocol-specific details of interfacing with particular underlying
protocols and present a consistent interface to the bundle layer.
The complexity of one convergence layer adapter may vary
substantially from another, depending on the type of underlying
protocol it utilizes. For example, a TCP/IP convergence layer
adapter for use in the Internet might only have to add message
boundaries to TCP streams, whereas a convergence layer adapter for
some network where no reliable transport protocol exists might be
considerably more complex (e.g., it might have to implement
reliability, fragmentation, flow-control, etc.) if reliable delivery
is to be offered to the bundle layer.
As convergence layer adapters implement protocols above and beyond
the basic bundle protocol specified in [RFC9171], they will be
defined in their own documents (in a fashion similar to the way
encapsulations for IP datagrams are specified on a per-underlying-
protocol basis, such as in RFC 894 [RFC894]).
6. Summary
The DTN architecture addresses many of the problems of heterogeneous
networks that must operate in environments subject to long delays and
discontinuous end-to-end connectivity. It is based on asynchronous
messaging and recognizes postal mail as a model of service classes
and delivery semantics. It introduces a relaxation of the End-to-End
Principle, offering assured end-to-end delivery by relying on the
retransmission capabilities of underlying protocols operating between
forwarding points on the end-to-end path. It accommodates many
different forms of connectivity, including scheduled, predicted, and
opportunistically connected delivery paths. It also proposes a model
for securing the network infrastructure against unauthorized access.
It is our belief that this architecture is applicable to many
different types of challenged environments.
7. Security Considerations
Security is an integral concern for the design of the Delay Tolerant
Network Architecture, but its use is optional. Sections
Section 4.1.3 and Section 5.14.3 of this document present some
factors to consider for securing the DTN architecture, but separate
documents [DTNSOV] and [RFC9172] define the security architecture in
more detail.
8. IANA Considerations
This document specifies the architecture for Delay Tolerant
Networking, which uses Internet-standard URIs for its Endpoint
Identifiers. URIs intended for use with DTN should be compliant with
the guidelines given in [RFC3986].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
9.2. Informative References
[AF03] Alonso, J. and K. Fall, "A Linear Programming Formulation
of Flows over Time with Piecewise Constant Capacity and
Transit Times", June 2003.
[ANY-MULTI-CAST]
Zhao, W., Ammar, M., and E. Zegura, "Multicast in Delay
Tolerant Networks", 2005.
[CK74] Cerf, V. and R. Kahn, "A Protocol for Packet Network
Intercommunication", May 1974.
[CT90] Clark, D. and D. Tennenhouse, "Architectural
Considerations for a New Generation of Protocols", 1990.
[DBFJHP04] Demmer, M., Brewer, E., Fall, K., Jain, S., Ho, M., and R.
Patra, "Implementing Delay Tolerant Networking", December
2004.
[DFS02] Durst, R., Feighery, P., and K. Scott, "Why not use the
Standard Internet Suite for the Interplanetary Internet?",
2002, <Available from
http://www.ipnsig.org/reports/TCP_IP.pdf>.
[DTNSOV] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant
Networking Security Overview", October 2006.
[FHM03] Fall, K., Hong, W., and S. Madden, "Custody Transfer for
Reliable Delivery in Delay Tolerant Networks", July 2003.
[FW03] Warthman, F., "Delay-Tolerant Networks (DTNs): A Tutorial
v1.1", 2003, <Available from http://www.dtnrg.org>.
[IGE00] Intanagonwiwat, C., Govindan, R., and D. Estrin, "Directed
Diffusion: A Scalable and Robust Communication Paradigm
for Sensor Networks", August 2000.
[IPN01] Internet Society Interplanetary Chapter, "InterPlaNetary
Chapter", n.d., <http://www.ipnsig.org>.
[ISCHEMES] IANA, "Uniform Resource Identifer (URI) Schemes", n.d.,
<http://www.iana.org/assignments/uri-schemes.html>.
[JDPF05] Jain, S., Demmer, M., Patra, R., and K. Fall, "Using
Redundancy to Cope with Failures in a Delay Tolerant
Network", 2005.
[JFP04] Jain, S., Fall, K., and R. Patra, "Routing in a Delay
Tolerant Network", Proceedings SIGCOMM , August 2004.
[KF03] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", Proceedings SIGCOMM , August 2003.
[LFC05] Leguay, J., Friedman, T., and V. Conan, "DTN Routing in a
Mobility Pattern Space", 2005.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000,
<https://www.rfc-editor.org/rfc/rfc2960>.
[RFC4088] Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform
Resource Identifier (URI) Scheme for the Simple Network
Management Protocol (SNMP)", RFC 4088,
DOI 10.17487/RFC4088, June 2005,
<https://www.rfc-editor.org/rfc/rfc4088>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/rfc/rfc792>.
[RFC894] Hornig, C., "A Standard for the Transmission of IP
Datagrams over Ethernet Networks", STD 41, RFC 894,
DOI 10.17487/RFC0894, April 1984,
<https://www.rfc-editor.org/rfc/rfc894>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/rfc/rfc9172>.
[S05] Scott, K., "Disruption Tolerant Networking Proxies for On-
the-Move Tactical Networks", October 2005.
[SB01] Burleigh, S., "Revisiting the Use of the IP Protocol Stack
in Deep Space", September 2024.
[SB03] Burleigh, S., Hooke, A., Torgerson, L., Fall, K., Cerf,
V., and B. Durst, "Delay-Tolerant Networking - An Approach
to Interplanetary Internet", IEEE Communications
Magazine , July 2003.
[T02] Thies, et al, W., "Searching the World Wide Web in Low-
Connectivity Communities", May 2002.
[WJMF05] Wang, Y., Jain, S., Martonosi, M., and K. Fall, "Erasure
Coding Based Routing in Opportunistic Networks", 2005.
[WSBL99] Adjie-Winoto, W., Schwartz, E., Balakrishnan, H., and J.
Lilley, "The Design and Implementation of an Intentional
Naming System", December 1999.
Acknowledgments
Authors' Addresses
Dr. Vinton G. Cerf
Google Corporation
13800 Coppermine Rd. Suite 384
Herndon, VA
USA
Email: vgcerf@gmail.com
Scott C. Burleigh
Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd, Laurel, MD 20723
USA
Email: sburleig.sb@gmail.com
Robert C. Durst
The MITRE Corporation
7515 Colshire Blvd., M/S H440
McLean, VA
USA
Email: durst@mitre.org
Dr. Kevin Fall
Intel Research, Berkeley
2150 Shattuck Ave.
Berkeley, CA
USA
Email: kfallca@gmail.com
Dr. Keith L. Scott
The MITRE Corporation
7515 Colshire Blvd., M/S H440
McLean, VA
USA
Email: kscott@mitre.org
Leigh Torgerson
Jet Propulsion Laboratory
4800 Oak Grove Drive, M/S 238-412
Pasadena, CA
USA
Email: jordan.l.torgerson@jpl.nasa.gov
Howard S. Weiss
SPARTA, Inc.
7075 Samuel Morse Drive
Columbia, MD
USA
Email: howard.weiss@parsons.com