DTN Research Group V. Cerf
INTERNET-DRAFT MCI/Jet Propulsion Laboratory
<draft-irtf-dtnrg-arch-03.txt> S. Burleigh
July 2005 A. Hooke
Expires January 2006 L. Torgerson
NASA/Jet Propulsion Laboratory
R. Durst
K. Scott
The MITRE Corporation
K. Fall
Intel Corporation
H. Weiss
SPARTA, Inc.
Delay-Tolerant Network Architecture
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document was produced by members of the IRTF's Delay Tolerant
Networking Research Group (DTNRG). See http://www.dtnrg.org for more
information.
Abstract
This document describes an architecture for delay-tolerant and
disruption-tolerant networks, and 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 message-
oriented overlay that exists above the transport (or other) layers of
the networks it interconnects. The document presents a motivation
for the architecture, an architectural overview, review of state
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
management required for its operation, and a discussion of
application design issues.
Cerf, et al. Expires January 2006 [Page 2]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................3
1 Introduction.................................................5
2 Why an Architecture for Delay-Tolerant Networking?...........6
3 DTN Architectural Description................................7
3.1 Virtual Message Switching using Store-and-Forward
Operation...............................................7
3.2 Nodes...................................................8
3.3 Endpoint Identifiers (EIDs) and Registrations...........8
3.4 Naming of Groups.......................................10
3.5 Priority Classes.......................................10
3.6 Postal-Style Delivery Options and Administrative Records11
3.7 Basic Bundle Fields....................................13
3.8 Routing and Forwarding.................................15
3.9 Fragmentation and Reassembly...........................16
3.10 Reliability and Custody Transfer.......................17
3.11 Time Stamps and Time Synchronization...................18
3.12 Congestion and Flow Control at the Bundle Layer........19
3.13 Security...............................................20
4 State Management Considerations.............................21
4.1 Application Registration State.........................21
4.2 Custody Transfer State.................................21
4.3 Bundle Routing and Forwarding State....................22
4.4 Security-Related State.................................22
5 Application Structuring Issues..............................23
6 Convergence Layer Considerations for Use of Underlying
Protocols...................................................24
7 Summary.....................................................24
8 Security Considerations.....................................25
9 IANA Considerations.........................................25
10 Normative References........................................25
11 Informative References......................................25
Cerf, et al. Expires January 2006 [Page 3]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
Acknowledgments
John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe
Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen
Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan
Symington and Craig Partridge all contributed useful thoughts and
criticisms to previous versions of this document. We are grateful
for their time and participation.
This work was performed in part under DOD Contract DAA-B07-00-CC201,
DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA
Contract NAS7-1407.
Release Notes
draft-irtf-ipnrg-arch-00.txt, May 2001:
Original Issue.
draft-irtf-ipnrg-arch-01.txt, August 2002:
-Restructured document to generalize architecture for delay-tolerant
networking.
-Refined DTN classes of service and delivery options. Added a
"reply-to" address to have response information such as error
messages or end-to-end acks directed to a source-specified third
party.
-Further defined the topological elements of delay tolerant networks.
-Elaborated routing and reliability considerations.
-Initial model for securing the delay tolerant network
infrastructure.
-Expanded discussion of flow and congestion control.
-Added section discussing state information at the bundle layer.
-Updated bundle header information and end-to-end data transfer.
draft-irtf-dtnrg-arch-00.txt, March 2003:
-Revised model for delay tolerant network infrastructure security.
-Introduced fragmentation and reassembly to the architecture.
-Removed significant amounts of rationale and redundant text. Moved
bundle transfer example(s) to separate draft(s).
draft-irtf-dtnrg-arch-02.txt, July 2004:
-Revised assumptions about reachability within DTN regions.
-Added management endpoint identifiers for nodes.
-Moved list of bundle header information to protocol spec document.
Draft-irtf-dtnrg-arch-03.txt, July 2005:
-Revised regions to become URI schemes
-Added discussion of multicast and anycast
-Revised motivation/introduction section (2) and
-Much of the security discussion has moved to the security draft
-Updated teminology to match current bundle spec
Cerf, et al. Expires January 2006 [Page 4]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
1 Introduction
This document describes an architecture for Delay and Disruption-
Tolerant interoperable networking. The architecture embraces the
concepts of occasionally-connected networks that may suffer from
frequent partitions and that may be comprised of more than one
divergent set 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 current DTN architecture described
here to be utilized in various operational environments, including
those subject to disruption and disconnection and those with high-
delay; the case of deep space is one specialized example of these,
and is being pursued as a specialization of this architecture (See
http://www.ipnsig.org 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].
We define an end-to-end message-oriented overlay called the "bundle
layer" that exists at a layer above the transport (or other) layers
of the networks on which it is hosted and below applications. Devices
implementing the bundle layer are called DTN nodes. The bundle layer
forms an overlay that employs persistent storage to help combat
network interruption. It includes a hop-by-hop transfer of reliable
delivery responsibility and optional end-to-end acknowledgement. It
also includes a number of diagnostic and management features. 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. It
also has a basic security model, optionally enabled, aimed at
protecting infrastructure from unauthorized use.
The bundle layer provides functionality similar to the internet layer
of gateways described in the original ARPANET/Internet designs
[CK74]. It differs from ARPANET gateways, however, because it is
layer-agnostic and is focused on virtual message forwarding rather
than packet switching. However, both 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-
Cerf, et al. Expires January 2006 [Page 5]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
and-forward message routing to overcome communication disruptions.
It provides services similar to 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.
2 Why an Architecture for Delay-Tolerant Networking?
The reason for pursuing 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].
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 retransmissions based on timely
and stable feedback from data receivers is an effective means for
repairing errors
- that end-to-end loss is relatively small
- that all routers and end stations support the TCP/IP protocols
- that applications need not worry about communication performance
- that endpoint-based security mechanisms are sufficient for meeting
most security concerns
- 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 many
and/or no end-to-end paths may ever exist); do not require end-to-
end reliability
- provide security mechanisms that protect the infrastructure from
unauthorized use as quickly as possible
- provide a coarse-grained class of service, delivery options, and
an expression of useful life for data to further allow the network
to better serve the needs of applications
Cerf, et al. Expires January 2006 [Page 6]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
In addition to the principles guiding the design of the bundle layer
itself, its use is also guided by a few application design
principles:
- applications should minimize the number of round-trip exchanges
- applications should cope with restarts after failure while network
transactions remain pending
These issues are discussed in further detail in Section 5.
3 DTN Architectural Description
The previous section summarized the design principles that guide the
definition of the DTN architecture. This section presents a
description of the major features of the architecture resulting from
design decisions guided by the aforementioned design principles.
3.1 Virtual Message Switching using Store-and-Forward Operation
A DTN-enabled application sends messages of arbitrary length (subject
to any implementation limitations). The relative order of messages
may not be preserved. Messages are transformed into protocol
"bundles" that may contain whatever the requesting application wishes
to send. Messages are sent by and delivered to applications in
complete units, although bundles may be split up during transmission
and possibly across an API between the application and the bundle
protocol agent. Message sources and destinations are identified by
(variable-length) Endpoint Identifiers (EIDs, described below).
Bundles also contain a "report-to" EID used when special operations
are requested to direct diagnostic output to an an arbitrary entity
(e.g., other than the source).
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 queuing and transmission delay. In contrast, the
DTN architecture does not expect that outbound links are always
available or reliable, and instead expects to store messages for some
time. We anticipate that most DTN nodes will use some form of
persistent storage for this -- disk, flash memory, etc., and that
stored messages will survive system restarts.
A message-oriented abstraction 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) would make such scheduling much more
difficult. Although packets provide some of the same benefits as
messages, larger aggregates provide a way for the network to apply
scheduling and buffer management to entire units of data that are
useful to applications.
Cerf, et al. Expires January 2006 [Page 7]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
An essential element of the message-based style of operation for
networking is that messages have a place to wait in a queue until an
outbound 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
messages 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.
3.2 Nodes
A DTN node (or simply "node" in this document) is an engine for
sending and receiving bundles-- an implementation of the bundle
layer. Applications utilize DTN nodes to send or receive messages
carried in bundles (or act as report-to destinations for diagnostic
information carried in bundles). Nodes are identified by one or more
Endpoint Identifiers (EIDs).
3.3 Endpoint Identifiers (EIDs) and Registrations
An Endpoint Identifier (EID) is a name, using the general syntax of
URIs (see below), that refers to a set of DTN nodes. In particular,
an EID may refer to one node (unicast), one of a group of nodes
(anycast), or all of a group of nodes (multicast and broadcast).
Applications send messages destined for an EID, and they may arrange
for data matching 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 purposes.
Applications utilize DTN nodes to send and receive messages to/from
Endpoint IDs. A single node may be a member of multiple Endpoint IDs
and an Endpoint ID may refer to more than one node (e.g., for anycast
and multicast delivery, see below). Each node is also required to
have at least one EID that uniquely identifies it.
An application's desire to receive traffic destined for a particular
EID is called a "registration," and in general is maintained
persistently by a DTN node. This allows application registration
information to survive application and operating system restarts.
An application's attempt to establish a registration is not
guaranteed to succeed. In particular, an application could request
to register itself as a member of an Endpoint ID that is
Cerf, et al. Expires January 2006 [Page 8]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
uninterpretable to the DTN node servicing the request. Such requests
are likely to fail.
3.3.1 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.
URIs are constructed based on rules specified in RFC 3986, using the
US-ASCII character set. However, note this excerpt from RFC 3986,
section 1.2.1, 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."
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 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 RFC 3986. Section 3.1 of RFC 3986 provides guidance on the
syntax of scheme names.
URI schemes are a key concept in the DTN architecture, and evolved
from an earlier concept called regions, which were tied more closely
to assumptions of the network topology. Using URIs, significant
flexibility is attained in the structuring of EIDs. They might, for
example, be constructed based on DNS names, or might look like
"expressions of interest" or forms of database-like queries as in a
directed diffusion-routed network [IGE00] or in intentional naming
[WSBL99]. As names, 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 may be
advantageous.
A single EID may refer to more than one DTN node, as suggested above.
It is the responsibility of a scheme designer to define how to
interpret the SSP of an EID so as to deterimine, using only
syntactical constructs, whether it refers to a unicast, multicast or
anycast set of nodes. See Section 3.4 for more details.
3.3.2 Late Binding
Binding means interpreting the SSP of an EID (possibly mapping it to
a lower-layer address or an alternate EID in a fashion similar to DNS
Cerf, et al. Expires January 2006 [Page 9]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
name-to-address mappings in the Internet) for the purpose of carrying
an associated message to a recipient over some underlying protocol.
"Late binding" means that this interpretation may take place
relatively late in the delivery process of a message. Late binding
is in contrast with typical Internet communication sessions in which
a DNS resolution takes place prior to data exchange at the IP layer.
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 disconnected network, late binding may be advantageous because
the transit time of a message may exceed the validity time of a
binding. Furthermore, 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 neighborhood of its
origin.
3.4 Naming of Groups
As mentioned above, an EID may refer to one node or a group of DTN
nodes. When referring to a group of nodes, the delivery semantics
may be of either the anycast or multicast variety (broadcast is
considered to be of the multicast variety). For anycast group
delivery, a message is delivered to one node among a group of
potentially many nodes, and for multicast delivery it is intended to
be delivered to all of them, subject to the normal DTN quality of
service and maximum useful lifetime semantics. Group join operations
are initiated at receivers.
Multicast group delivery in a DTN presents an unfamiliar issue with
respect to group membership. In relatively low-delay networks, such
as the Internet, nodes may be considered to be part of the group if
they have expressed interest to join it "recently." In a DTN,
however, nodes may wish to receive data sent to a group during an
interval of time earlier than when they are actually able to receive
it [ZAZ05]. More precisely, an application expresses its desire to
receive data sent to EID e at time t. Prior to this, during the
interval [t0, t1], t > t1, data may have been generated for group e.
For the application to receive any of this data, the data must be
available a potentially long time after senders have ceased sending
to the group. Thus, the data may need to be stored within the
network in order to support temporal group semantics of this kind.
How to design and implement this remains a research issue, as it is
likely to be at least as hard as problems related to reliable
multicast.
3.5 Priority Classes
The DTN architecture offers *relative* measures of priority (low,
medium, high) for delivering traffic. These priorities differentiate
traffic based upon an application's desire to affect the delivery
urgency for messages. The architecture also offers other, optional
Cerf, et al. Expires January 2006 [Page 10]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
notifications and handling instructions (see below) that additionally
affect the exact handling of message delivery within the network.
The (U.S. or similar) Postal Service provides a strong metaphor for
the priority classes offered by the DTN architecture. Traffic is
generally not interactive and may be one-way. There are generally no
strong guarantees of timely delivery, yet there are some forms of
class of service, reliability, and security.
We have currently defined three relative priority classes. These
priority classes typically imply some relative scheduling
prioritization among bundles in queue at a sender:
- 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.
Applications specify their requested priority class and data lifetime
(see below) for each message they send. This information, coupled
with policy applied at DTN nodes that forward messages and routing
algorithms in use, affects the overall likelihood and timeliness of
message delivery.
The priority class of a message is relative to its source's priority
assignment. Depending on a particular DTN's forwarding policy, it
may also be enforced *between* sources. That is, in some DTNs
expedited bundles will always be sent prior to any bulk bundles,
irrespective of source. Other DTNs may behave differently.
3.6 Postal-Style Delivery Options and Administrative Records
Continuing with the postal analogy of message delivery, the DTN
architecture supports several delivery options that may be selected
by a source when it requests the transmission of a bundle. In
addition, there are two types of administrative records called status
reports and signals. These records are bundles that provide
information about the delivery of other bundles, and are used in
conjunction with the delivery options.
3.6.1 Delivery Options
We have currently agreed upon six delivery options. Applications may
request any combination of the following ones:
- Custody Transfer Required - requests a bundle be delivered with
enhanced reliability using custody transfer procedures. A bundle
will be transmitted by the bundle layer using reliable transfer
protocols (if available), and the responsibility for reliable
Cerf, et al. Expires January 2006 [Page 11]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
delivery of the bundle to its destination(s) may move among one or
more "custodians" in the network. This capability is described in
more detail in Section 3.10.
- Report when Bundle Delivered - requests a Bundle Delivery Status
Report bundle be generated when the bundle reaches its intended
recipient(s).
- Report when Bundle Forwarded - requests a Bundle Forwarded Status
Report bundle be generated when the subject bundle departs a DTN
node that has forwarded it.
- Report when Bundle Received - requests a Bundle Received Status
Report bundle be generated when the subject bundle arrives at a
DTN node.
- Report when Bundle Deleted - requests a Bundle Deleted Status
Report bundle be generated when the subject bundle is deleted at a
DTN node.
- Report when Bundle Custody Accepted - requests a Custody Transfer
Report bundle be generated when the subject bundle has been
accepted using custody transfer.
If the security procedures defined in [DTNSEC] are also enabled, then
three additional delivery options become available:
- Confidentiality Required - requests a bundle's data be made secret
from parties other than the source and the members of the
destination EID
- Authentication Required - requests the source's identity in a
bundle be made strongly verifiable (i.e. cryptographically strong)
to members of its destination EID
- Error Detection Required - requests a bundle's data be made
strongly verifiable against modification during transmission (i.e.
cryptographically strong)
3.6.2 Bundle Status Reports and Custody Signals
Bundle Status Reports (BSRs) provide information and diagnostic
responses in DTN and correspond (approximately) to the ICMP protocol
in IP [RFC792]. In ICMP, however, messages are returned to the
source. In DTN, they are instead directed to the report-to EID,
rather than the source's EID. BSRs are sent as bundles with a source
EID set to one of the EIDs associated with the DTN node generating
the BSR. The report-to EID in a bundle may be the same as its source
EID. In some cases, arrival of a single bundle or bundle fragment
may elicit multiple BSRs (e.g., in the case where a bundle is
replicated for multicast forwarding).
Cerf, et al. Expires January 2006 [Page 12]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
The following BSRs are currently defined (also see [BSPEC] for more
details):
- Bundle Reception - sent when a bundle arrives at a DTN node
- Custody Acceptance - sent when a node has accepted custody of a
bundle with the Custody Transfer Required option set
- Bundle Forwarded - sent when a bundle containing a Report when
Bundle Forwarded option departs from a DTN node after having been
forwarded.
- Bundle Delivery - sent from a final recipient's (destination) node
when a bundle containing a Report when Bundle Delivered option is
consumed by an application
- Bundle Deletion - sent from a DTN node when a bundle containing a
Report when Bundle Deleted option is discarded. This can happen
for several reasons, such as expiration
In addition to the status reports, a signal is currently defined to
indicate the status of a custody transfer. These are sent to the
current-custodian EID contained in an arriving bundle:
- Custody Signal - indicates that custody has been successfully
transferred. This signal appears as a boolean indicator, and may
therefore indicate either a successful or a failed custody
transfer attempt
3.7 Basic Bundle Fields
The bundles carried between and among DTN nodes obey a standard
bundle protocol specified in [BSPEC]. Here we provide an overview of
most of the fields carried with every bundle. The protocol is
designed with a basic header, a payload header, and a set of optional
extension headers, similar to the approach taken by IPv6. The
following fields are all present in the basic header, and therefore
are present for every bundle and fragment:
- Bundle Creation Time - the time-of-day an application requested a
message to be sent (and a bundle containing the message was formed
by the sender's DTN node). DTN nodes are assumed to have a basic
time synchronization capability (see Section 3.11).
- Lifespan - indicates the time-of-day at which the message is no
longer useful. If a bundle is stored in the network (including the
sender's DTN node) when its expiration time is reached, it may be
discarded. The expiration time of a bundle is expressed as an
offset relative to its Bundle Creation Time.
- Priority Class - bulk, normal, or expedited
- Source EID - EID of the (original) sender
Cerf, et al. Expires January 2006 [Page 13]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
- Destination EID - EID of the final intended recipient(s)
- Report-To Endpoint ID - an EID identifying where reports (return-
receipt, route-tracing functions) should be sent. This may
identify the same node as the Source EID.
- Current Custodian EID - EID of the current custodian of a bundle
- Request Options - See Section 3.6.1.
The payload header indicates information about the contained payload
(e.g. its length). In addition to the fields found in the basic and
payload headers, each bundle may have fields present in the zero or
more extension headers carried with each bundle. See [BSPEC] for
additional details.
Cerf, et al. Expires January 2006 [Page 14]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
3.8 Routing and Forwarding
The DTN architecture provides a framework for routing and forwarding
at the bundle layer for unicast, anycast, and multicast messages.
Interconnections among DTN nodes can be described abstractly with a
directed, time-varying multigraph. Multiple edges in the graph
between the same pair of vertices correspond to distinct
communications technologies being available to transfer data between
them. Edges in this graph are, in general, time-varying with respect
to their delay and capacity. Edges with zero capacity are considered
to not be connected. Capacities and delays are therefore time-
varying, and are typically described from the point-of-view of the
"tail" of a directed edge. This is necessary because the delay may
be significant-- e.g., when the "head" of the edge is at positive
capacity the "tail" of the edge may not be.
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 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) [JPF04]. Optimally using a
contact's volume, however, requires the ability to divide large
messages into smaller routable units. This is provided by DTN
fragmentation (see Section 3.9).
When delivery paths through the DTN graph are lossy, or contact
intervals and volumes are not known precisely ahead of time, routing
computations become especially challenging. How to handle these
situations is an active area of work in the (emerging) research area
of Delay Tolerant Networking.
3.8.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 identified:
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 representatives of this class.
On-Demand Contacts
On-Demand contacts require some action in order to instantiate, but
then function as persistent contacts until terminated. A dial-up
Cerf, et al. Expires January 2006 [Page 15]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
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
"particular time" is delay-dependent. For example, a single
scheduled contact between Earth and Mars would not be 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 undetermined 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].
3.9 Fragmentation and Reassembly
DTN fragmentation and reassembly is designed to improve the
efficiency of message transfers by ensuring that contact volumes are
fully utilized and by avoiding re-transmission of partially-
forwarded messages. There are two forms of DTN
fragmentation/reassembly:
Any DTN node may - proactively - divide a block of application data
into multiple smaller blocks and transmit each such block as an
independent bundle. In this case the *final destination(s)* are
responsible for extracting the smaller blocks from incoming bundles
and reassembling them into the original larger bundle. This
approach is used primarily when contact volumes are known (or
predicted) in advance.
Cerf, et al. Expires January 2006 [Page 16]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
DTN nodes sharing an edge may -reactively- fragment a bundle
cooperatively when a bundle is only partially transferred. In this
case, the receiving bundle protocol agent modifies the incoming
bundle to indicate it is a fragment, and forwards it normally. The
previous-hop sender may learn that only a portion of the bundle was
delivered to the next hop, and send the remaining portion when
subsequent contacts become available.
The reactive fragmentation capability is not required to be
available in every DTN implementation, and presents significant
challenges with respect to handling digital signatures and
authentication codes on messages. However, the ability to re-
assemble fragments at a destination is required. Furthermore, for
contacts with volumes that are small compared to typical bundle
sizes, some incremental delivery approach must be used (e.g.
checkpoint/restart) to prevent data delivery livelock. Reactive
fragmentation is one such approach, but other protocol layers could
potentially handle this issue as well.
3.10 Reliability and Custody Transfer
The bundle layer provides unacknowledged, prioritized (but not
guaranteed) message delivery. It also provides two options for
enhancing delivery reliability: end-to-end acknowledgments and
custodial delivery. Applications wishing to implement their own end-
to-end message reliability mechanisms are free to utilize the
acknowledgment. The DTN architecture only specifies a coarse-grained
retransmission capability, described next.
Delivering bundles with the Custodial Transfer Required option
specified generally involves moving the responsibility for reliable
delivery of the message among different DTN nodes in the network.
For unicast delivery, this will typically involve moving a copy of
the message "closer" (in terms of some routing metric) to its
ultimate destination. The nodes receiving these copies along the way
(and agreeing to accept the reliable delivery responsibility) are
called "custodians." The movement of a message (and its delivery
responsibility) from one node to another is called a "custody
transfer." It is analogous to a database commit transaction [FHM03].
The exact meaning and design of custody transfer for multicast and
anycast delivery remains to be fully explored.
Custody transfer allows the source to delegate retransmission
responsibility and recover its retransmission-related resources
relatively soon after sending a bundle (on the order of the minimum
round-trip time to the first bundle hop(s)). Not all nodes in a DTN
are required by the DTN architecture to accept custody transfers, so
it is not a true 'hop-by-hop' mechanism. For example, some nodes may
have sufficient storage resources to sometimes act as custodians, but
may elect to not offer such services when congested or running low on
power.
Cerf, et al. Expires January 2006 [Page 17]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
The existence of custodians can alter the way DTN routing is
performed. In some circumstances, it may be beneficial to move a
message to a custodian as quickly as possible even if it is further
away (in terms of distance, time or some routing metric) from the
final destination(s). Designing a system with this capability
involves constructing more than one routing graph, and is an area of
continued research.
Custody transfer in DTN not only provides a method for tracking and
moving the responsibility for reliable message delivery but also
provides a (weak) mechanism for implementing reliable delivery.
Generally speaking, custodial delivery relies on underlying reliable
delivery protocols of the networks that it operates over to provide
the primary means of reliable transfer from one bundle node to the
next (set). However, when custodial delivery is requested, the
bundle layer provides an additional coarse-grained timeout and
retransmission mechanism and an accompanying (bundle-layer)
custodian-to-custodian acknowledgment mechanism. When an application
does *not* request custodial delivery, this bundle layer timeout and
retransmission mechanism is not employed, and successful bundle layer
delivery depends solely on the reliability mechanisms of the
underlying protocols.
When a node accepts custody for a bundle that contains the Custody
Transfer Required option, a Custody Transfer Accepted Signal is sent
by the bundle protocol agent to the Current Custodian EID contained
in the bundle header. In addition, the Current Custodian EID is
updated to contain one of the forwarding node's (unicast) EIDs before
the bundle is forwarded.
3.11 Time Stamps and Time Synchronization
The DTN architecture depends on time synchronization among DTN nodes
(supported by external, non-DTN protocols) for four primary purposes:
bundle and fragment identification, routing with scheduled or
predicted contacts, bundle expiration time computations, and
application registration expiration.
Bundle identification and expiration are supported by placing a time
stamp and an explicit expiration field (expressed in seconds after
the source time stamp) in each bundle header. The origination time
stamp on an arriving bundle is made available to consuming
applications by some system interface function. Each bundle is
required to contain a time stamp unique to the bundle sender's EID.
The concatenation of the Source EID and the time stamp serves as a
unique identifier for a particular bundle, and is used for a number
of purposes, including custody transfer and reassembly of bundle
fragments.
Time is also used in conjunction with application registrations.
When an application expresses its desire to receive data for a
particular EID, this registration is only maintained for a finite
period of time, specified by the application. For multicast
Cerf, et al. Expires January 2006 [Page 18]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
registrations, an application also specifies a time range or
"interest interval" for its registration. In this case, traffic sent
to the specified EID any time during the specified interval will
eventually be delivered to the application (unless such traffic has
expired due to the expiration time).
3.12 Congestion and Flow Control at the Bundle Layer
The subject of congestion control and flow control at the bundle
layer is one on which the authors of this document have not yet
reached complete consensus. We have unresolved concerns about the
efficiency and efficacy of congestion and flow control schemes
implemented across long and/or highly variable delay environments,
especially with the custody transfer mechanism that may require nodes
to retain messages for long periods of time.
For the purposes of this document, we define "flow control" as a
means of assuring that the rate at which a sending node transmits
data to a receiving node does not exceed the maximum 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 a certain degree of
freedom in handling the situation. It can always discard bundles
which have expired-- an activity DTN nodes should perform regularly
in any case. If it ordinarily is willing to accept custody for
bundles, it can cease doing so. It can also discard bundles which
have not expired but for which it has not accepted custody. A node
must avoid discarding bundles for which it has accepted custody.
Determining when a node should engage in or cease to engage in
custody transfers is a resource allocation and scheduling problem of
current research interest.
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 affecting 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
Cerf, et al. Expires January 2006 [Page 19]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
blocking issues, depending on the nature of bundle multiplexing
within a TCP connection. A protocol with more relaxed ordering
constraints (e.g. SCTP [RFC2960]) might be preferable in such
circumstances.
3.13 Security
The possibility of severe resource scarcity in some delay-tolerant
networks dictates that some form of authentication and access control
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 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 [DTNSEC] that utilizes both a hop-by-
hop and an (optional) end-to-end authentication mechanism. The
purpose of using both mechanisms is to be able to handle access
control for data forwarding separately from application-layer data
integrity. While the end-to-end mechanism provides authentication
for a principal such as a user (of which there may be many), the hop-
by-hop mechanism is intended to authenticate DTN nodes as legitimate
transceivers of bundles to each other. Note that it is conceivable
to construct a DTN in which only a subset of the nodes participate in
the security mechanisms, resulting in a secure DTN overlay existing
atop an insecure DTN overlay, but this idea is relatively new and is
still being explored.
Cerf, et al. Expires January 2006 [Page 20]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
In accordance with the goals listed above, DTN nodes discard traffic
as early as possible if authentication or access control 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 storage overhead required at DTN nodes.
4 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.
4.1 Application Registration State
In long/variable delay environments, an asynchronous application
interface seems most appropriate. Such interfaces typically include
methods for applications to register callback actions when certain
triggering events occur (e.g. when messages arrive). These
registrations create state information called application
registration state.
Application registration 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 message 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 registration 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 a registration and thereby establish application
registration state, an application specifies an Endpoint ID for which
it wishes to receive messages, along with a time value indicating how
long the registration should remain active. This operation is
somewhat analogous to the bind() operation in the common sockets API.
For registrations to groups (i.e., joins), a time interval is also
required. The time interval refers to the range of origination times
of messages sent to the specified EID. See Section 3.4 above for
more details.
4.2 Custody Transfer State
Cerf, et al. Expires January 2006 [Page 21]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
Custody transfer state includes information required to keep account
of bundles for which a node has taken custody, as well as the
protocol state related to transferring custody for one or more of
them. The accounting-related state is created when a bundle is
received. Custody transfer retransmission state is created when a
transfer of custody is initiated by forwarding a bundle with the
custody transfer required delivery option specified. Retransmission
state and accounting state are released upon receipt of one or more
Custody Transfer Succeeded signals, indicating custody has been
moved. In addition, the bundle's expiration time (possibly mitigated
by local policy) provides an upper bound on the time when this state
is purged from the system in the event that it is not purged
explicitly due to receipt of a signal.
4.3 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 message from one DTN node to another. Routing
makes use of routing state (the RIB, or routing information base),
while forwarding makes use of state 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 links 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 class of service and the location of potential custodians
(for custody transfer, see section 3.10), 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 is still under study.
4.4 Security-Related State
The DTN security approach described in [DTNSEC], 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. All cached information has
expiration times, and nodes are responsible for acquiring and
distributing updates of public information and credentials prior to
the expiration of the old set (in order to avoid a disruption in
network service).
Cerf, et al. Expires January 2006 [Page 22]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
In addition to basic end-to-end and hop-by-hop authentication, 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.
Some DTNs may implement security boundaries enforced by selected
nodes in the network, where end-to-end credentials may be checked in
addition to checking the hop-by-hop credentials. (Doing so may
require routing to be adjusted to ensure complete bundles pass
through these points). Public information used to verify end-to-end
authentication will typically be cached at these points.
5 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). 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 a
message so that it may be treated as an independent unit of work by
the receiving entity. (This represents a form of "application data
unit" [CT90]). The goal is to minimize synchronous interchange
between applications that are separated by 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.
Cerf, et al. Expires January 2006 [Page 23]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
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.
6 Convergence Layer Considerations for Use of Underlying Protocols
Implementation experience with the DTN architecture has revealed an
important architectural construct and interface 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 a set of
convergence layers placed between the bundle layer and underlying
protocols. The convergence layers 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 may vary substantially from
another, depending on the type of underlying protocol it adapts. For
example, a TCP/IP convergence layer for use in the Internet might
only have to add message boundaries to TCP streams, whereas a
convergence layer 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 layers implement protocols above and beyond the basic
bundle protocol specified in [BSPEC], 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]).
7 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 uses postal mail as a model of service classes and
delivery semantics. It accommodates many different forms of
connectivity, including scheduled, predicted, and opportunistically
connected links. It introduces a novel approach to end-to-end
reliability across frequently partitioned and unreliable networks.
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.
Cerf, et al. Expires January 2006 [Page 24]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
8 Security Considerations
Security is an integral concern for the design of the Delay Tolerant
Network Architecture, but its use is optional. Section 3.13 of this
document presents some factors to consider for securing the DTN
architecture, but a separate document [DTNSEC] defines the security
architecture in much more detail.
9 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].
10 Normative References
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3978, March 2005.
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifier (URI): Generic Syntax", STD 66, RFC 3986, Jan 2005.
11 Informative References
[SB03] S. Burleigh et al, "Delay-Tolerant Networking - An Approach to
Interplanetary Internet," IEEE Communications Magazine, July 2003.
[FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial
v1.1," Wartham Associates, 2003. Available from
http://www.dtnrg.org.
[KF03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged
Internets," Proceedings SIGCOMM, Aug 2003.
[JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant
Network," Proceedings SIGCOMM, Aug/Sep 2004.
[DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard
Internet Suite for the Interplanetary Internet?", MITRE White Paper,
2002. Available from http://www.ipnsig.org/reports/TCP_IP.pdf
[CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network
Intercommunication," IEEE Trans. on Comm., COM-22(5), May 1974.
[IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed
Diffusion: A scalable and robust communication paradigm for sensor
networks," Proceedings MobiCOM, Aug 2000.
Cerf, et al. Expires January 2006 [Page 25]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
[WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley,
"The design and implementation of an intentional naming system",
Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999.
[CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a
new generation of protocols," Proceedings SIGCOMM, 1990.
[ISCHEMES] http://www.iana.org/assignments/uri-schemes
[JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy to
Cope with Failures in a Delay Tolerant Network," Proceedings SIGCOMM
2005.
[WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure coding
based routing in opportunistic Networks", Proceedings SIGCOMM
Workshop on Delay Tolerant Networks, 2005.
[ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay Tolerant
Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks,
2005.
[LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a Mobility
Pattern Space", Proceedings SIGCOMM Workshop on Delay Tolerant
Networks, 2005.
[AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of Flows
over Time with Piecewise Constant Capacity and Transit Times", Intel
Research Technical Report IRB-TR-03-007, June 2003.
[FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable
Delivery in Delay Tolerant Networks", Intel Research Technical Report
IRB-TR-03-030, July 2003.
[RFC2960] R. Stewart et. al., "Stream Control Transmission Protocol",
RFC 2960, Oct. 2000.
[BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification",
draft-irtf-dtnrg-bundle-spec-02.txt, Work in Progress, July 2005.
[DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security
Protocol Specification", draft-irtf-dtnrg-bundle-security-00.txt,
Work in Progress, June 2005.
[DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra,
"Implementing Delay Tolerant Networking", Intel Research Technical
Report IRB-TR-04-020, Dec. 2004.
[RFC894] C. Hornig, "Standard for the Transmission of IP Datagrams
over Ethernet Networks", RFC 894, Apr 1984.
Authors' Addresses
Cerf, et al. Expires January 2006 [Page 26]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
Dr. Vinton G. Cerf
MCI Corporation
22001 Loudoun County Parkway
Building F2, Room 4115, ATTN: Vint Cerf
Ashburn, VA 20147
Telephone +1 (703) 886-1690
FAX +1 (703) 886-0047
Email vcerf@mci.net
Scott C. Burleigh
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 179-206
Pasadena, CA 91109-8099
Telephone +1 (818) 393-3353
FAX +1 (818) 354-1075
Email Scott.Burleigh@jpl.nasa.gov
Robert C. Durst
The MITRE Corporation
7515 Colshire Blvd.
M/S H300
McLean, VA 22102
Telephone +1 (703) 883-7535
FAX +1 (703) 883-7142
Email durst@mitre.org
Dr. Kevin Fall
Intel Research, Berkeley
2150 Shattuck Ave., #1300
Berkeley, CA 94704
Telephone +1 (510) 495-3014
FAX +1 (510) 495-3049
Email kfall@intel.com
Adrian J. Hooke
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: 303-400
Pasadena, CA 91109-8099
Telephone +1 (818) 354-3063
FAX +1 (818) 393-3575
Email Adrian.Hooke@jpl.nasa.gov
Dr. Keith L. Scott
The MITRE Corporation
7515 Colshire Blvd.
M/S H300
McLean, VA 22102
Telephone +1 (703) 883-6547
FAX +1 (703) 883-7142
Email kscott@mitre.org
Cerf, et al. Expires January 2006 [Page 27]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
Leigh Torgerson
Jet Propulsion Laboratory
4800 Oak Grove Drive
M/S: T1710-
Pasadena, CA 91109-8099
Telephone +1 (818) 393-0695
FAX +1 (818) 354-9068
Email Leigh.Torgerson@jpl.nasa.gov
Howard S. Weiss
SPARTA, Inc.
9861 Broken Land Parkway
Columbia, MD 21046
Telephone +1 (410) 381-9400 x201
FAX +1 (410) 381-5559
Email hsw@sparta.com
Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay
Tolerant Networking Research Group (DTNRG) web site is located at
http://www.dtnrg.org.
Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
Cerf, et al. Expires January 2006 [Page 28]
Internet Draft draft-irtf-dtnrg-arch-03.txt July 2005
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Cerf, et al. Expires January 2006 [Page 29]