One document matched: draft-irtf-dtnrg-arch-01.txt
Differences from draft-irtf-dtnrg-arch-00.txt
DTN Research Group V. Cerf
INTERNET-DRAFT MCI/Jet Propulsion Laboratory
<draft-irtf-dtnrg-arch-01.txt> S. Burleigh
October 2003 A. Hooke
Expires April 2003 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
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 within the IRTF's Delay Tolerant
Networking Research Group (DTNRG). The charter documents for this
research group can be found at http://www.irtf.org. Other
information may be found at the research group's web site:
http://www.dtnrg.org.
Abstract
This document describes the Delay-Tolerant Networking (DTN)
Architecture. It aims to present a system for providing
interoperable communications across a variety of internetworks with
operational and performance characteristics that make conventional
(Internet-like) networking approaches either unworkable or
impractical. It is a generalization of the IPN architecture
originally designed for the Interplanetary Internet [B03]. We define
a message-oriented overlay that exists above the transport layer of
the networks on which it is hosted. The document presents an
architectural overview followed by discussions of services, topology,
routing, security, reliability and state management.
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
Table of Contents
Status of this Memo................................................1
Abstract...........................................................1
Table of Contents..................................................2
1 Introduction................................................4
2 Why an Architecture for Delay-Tolerant Networking?..........4
2.1 Problems with the Existing Internet Protocols..........4
2.2 DTN Design Principles..................................5
3 DTN Architectural Description...............................5
3.1 Virtual Message Switching..............................5
3.2 Store and Forward Operation............................6
3.3 DTN Delivery Mimics Postal Operations..................7
3.4 Nodes and Agents.......................................9
3.5 Regions and Gateways..................................10
3.6 Tuples................................................12
3.7 Late Binding..........................................13
3.8 Routing...............................................13
3.9 Bundle Fragmentation and Reassembly...................16
3.10 Bundle Layer Reliability and Custody Transfer.........17
3.11 Time Synchronization..................................17
3.12 Congestion and Flow Control at the Bundle Layer.......18
3.13 Security..............................................19
4 State Management Considerations............................20
4.1 Demultiplexing and Binding State......................21
4.2 Bundle Retransmission State...........................21
4.3 Bundle Routing State..................................21
4.4 Security-Related State................................22
5 Bundle Header Information..................................22
6 Application Structuring Issues.............................23
7 Convergence Layer Considerations for Use of Underlying
Protocols..................................................24
8 Summary....................................................25
9 Informative References.....................................25
10 Security Considerations....................................26
11 Authors' Addresses.........................................27
12 Intellectual Property Notices..............................28
13 Copyright Notices..........................................28
Cerf, et al. Expires April 2004 [Page 2]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
Acknowledgments
John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe
Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen
Farrell 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 History
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-01.txt, October 2003:
-Generalized model language to accommodate the possibility of using
Identity Based Encryption (IBE)
-Small extension to custody discussion.
-Introduced a list of what applications always specify when
requesting a bundle to be sent.
Cerf, et al. Expires April 2004 [Page 3]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
1 Introduction
This document describes a data communications architecture for Delay
and Disconnection-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 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 high-delay and unusual environments;
the case of deep space is one of these, and is still being pursued as
a specialization of this architecture (See http://www.ipnsig.org and
[B03] for more details). Other networks to which we believe this
architecture may apply include sensor-based networks using scheduled
intermittent connectivity, classes of terrestrial wireless networks
that cannot ordinarily maintain end-to-end connectivity, and more
"conventional" internets with long delays. A DTN tutorial [W03],
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. A technical description may be found in
[F03].
The particular approach we employ is that of an end-to-end message-
based overlay that exists above the transport layers of the networks
on which it is hosted. The overlay employs persistent storage at
intermediate message switches, includes a hop-by-hop transfer of
reliable delivery responsibility, and provides an optional end-to-end
acknowledgement. For interoperability it includes a flexible naming
format (based on URIs) capable of encapsulating different naming
schemes in the same overall naming format. It also has a basic
security model aimed at protecting infrastructure from unauthorized
use.
2 Why an Architecture for Delay-Tolerant Networking?
The reason for pursuing an architecture for delay tolerant networking
stems from experience gained while attempting to impose Internet-
style networking over networks for which it was not designed. In so
doing, several particular problems related to built-in assumptions of
the Internet protocols are encountered. Understanding the
limitations posed by these assumptions leads to a set of design
principles that guide the DTN architectural design. These factors
are summarized below; more detail on their rationale can be found in
[B03,F03,DFS02].
2.1 Problems with the Existing Internet Protocols
The existing Internet Protocols do not work well for some
environments, due to fundamental assumptions built into the Internet
architecture:
Cerf, et al. Expires April 2004 [Page 4]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
- that an end-to-end path between source and destination exists for
the duration of the communication session;
- (for reliable communication) that the maximum round-trip time over
that path is not excessive and not highly variable from packet to
packet
- that the end-to-end packet loss is relatively small
- that all routers and end stations support the TCP/IP protocols
- that applications need not worry about the performance of
underlying physical links
- that endpoint-based security mechanisms are sufficient for meeting
most security concerns
In several networks one or more of these assumptions may be violated.
In addition, these networks are often unusual and not designed with
interoperability in mind. Thus, a DTN design should facilitate
operation among poorly-connected networks but also provide a
mechanism to achieve interoperability among such networks.
2.2 DTN Design Principles
In light of these assumptions, coupled with the desire to communicate
through and among networks with radically different performance
characteristics, the DTN architecture is conceived based on a number
of design principles that are summarized here:
- provide a coarse-grained class of service and delivery options
based on non-real-time services provided by the US (and other)
postal systems
- 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
- encourage applications to minimize round-trip exchanges
- guide application design to cope with application restart after
failure while network transactions remain pending
- use storage within the network to support end-to-end reliable
delivery of messages, even if these networks suffer from frequent
partitioning or high data loss (e.g. support operation in
environments where no end-to-end path may ever exist)
- provide security mechanisms that protect the infrastructure from
unauthorized use; if appropriate, provide access to these
mechanisms by applications for use in their own application-level
security protocols
3 DTN Architectural Description
The previous section summarized the design principles that guide the
definition of the DTN architecture. This section outlines the design
decisions that result from those design principles.
3.1 Virtual Message Switching
Cerf, et al. Expires April 2004 [Page 5]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
A DTN-enabled application specifies either a file-based or memory-
based copy of data to be transmitted by a nearby (local) DTN
forwarding agent using a specialized API. The agent forms a "bundle"
containing whatever the requesting application wishes to send, plus
some header information it creates. Bundles are also called
"messages" in this document. Data submitted by applications can be of
arbitrary length (subject to any implementation limitations), as can
bundles. Bundles preserve application message boundaries:
application data are written and read in an atomic fashion, although
bundles may be split up during transmission and their relative order
may not be preserved. Generally, forwarding agents (executing as
applications) send messages among themselves above the transport
layers of the networks they interconnect, forming an overlay network
called the "bundle layer."
Bundles contain (variable-length) names ("tuples") that identify the
sender and intended receiver of a message. A sending application
typically forms the sending tuple identifier by combining information
it learns from its local forwarding agent, in combination with its
own application-specific data. The resulting tuple provides enough
information for a receiving application to reply. The destination
tuple is also supplied by the application. It is interpreted by the
forwarding agent as little as possible: only that portion of the
destination tuple required for determining the next hop is
interpreted. The rest is treated as opaque data, allowing the
overall naming system to take advantage of late binding (see Section
3.7). In adition to the sender and receiver tuples, messages may
also contain an optional "report-to" tuple used when special
operations are requested to direct diagnostic and delivery
notification messages to an entity other than the sender.
A message-switched abstraction provides the bundle layer with a-
priori knowledge of the size and performance requirements of
requested data transfers. When there is resource contention in the
network, the advantage provided by knowing this information may be
significant for making scheduling and path selection decisions. An
alternative abstraction (i.e. of stream based delivery) would make
such scheduling very difficult. Although packets provide some of the
same benefits as messages, larger aggregates provide a way for the
network to make scheduling, buffer management and path selection
decisions to entire units of data that are meaningful to
applications.
3.2 Store and Forward Operation
An essential element of virtual switching of messages is that they
have a place to wait in a queue until an outbound communication
opportunity ("contact") becomes available. This highlights the
following assumptions:
1. that storage is available and well-distributed throughout the
network
Cerf, et al. Expires April 2004 [Page 6]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
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 use other approaches such as TCP/IP or
other alternatives that require continuous connectivity
For a network to effectively support the DTN architecture, these
assumptions must be considered and must be found to hold.
3.3 DTN Delivery Mimics Postal Operations
The (U.S. or similar) Postal Service provides a strong metaphor for
the services that a Delay-Tolerant Network offers. Traffic is
generally not interactive. It may be one-way in nature. There are
generally no strong guarantees of timely delivery (with some limited
exceptions), yet there are some forms of class of service and
security. Postal services have evolved over hundreds of years and
serve a very large and diverse user community. They have therefore
already explored various service classes and special delivery
options, which we leverage here for the DTN architecture.
The DTN Architecture, like the most postal services, offers
*relative* measures of priority (low, medium, high which correspond
roughly to bulk, first class, and express mail). It also offers
basic special delivery options, for example: "the intended recipient
has accepted delivery of the message," "the route taken by this
message is as follows...", and "the message has been accepted for
transmission."
3.3.1 DTN Classes of Service
We have currently defined three specific classes of service in the
DTN architecture, based on their postal mail counterparts:
- Bulk - In bulk class, bundles are shipped on a "best effort"
basis. No bulk class bundle will be shipped until all complete
bundles of other classes bound for the same next hop destination
have been shipped.
- Normal - Normal class bundles that are in queue and bound for the
same next hop destination are shipped prior to any complete bulk
class bundles that are in queue.
- Expedited - Expedited bundles, in general, are shipped prior to
bundles of other classes. However, the bundle layer *may*
implement a queue service discipline that prevents starvation of
the normal class, which may result in some normal bundles being
shipped before expedited bundles bound for the same next hop
destination as the normal class bundles.
Cerf, et al. Expires April 2004 [Page 7]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
Applications specify their requested class of service. This request,
coupled with policy applied at message switches, affects the overall
likelihood and timeliness of message delivery.
3.3.2 DTN Postal-Style Delivery Options
Applications may request any of the following five delivery options:
- Custodial Delivery - a bundle will be transmitted by the bundle
layer using reliable transport protocols (if available), and the
point of reliable delivery responsibility (i.e. retransmission
buffer) will advance through the network from one custodian to
another until the bundle reaches its destination. The bundle
layer depends on the underlying transport protocols of the
networks that it operates over to provide the primary means of
reliable transfer from one bundle layer to the next. However,
when custodial delivery is requested, the bundle layer provides an
additional coarse-grained timeout and retransmission mechanism and
an accompanying (bundle-layer) hop-by-hop acknowledgment
mechanism. When a bundle 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 transport
layers
- Return Receipt - a return-receipt bundle is issued by the
receiving bundle layer implementation when the (arriving) subject
bundle is consumed *by the destination application* (not simply
the destination bundle layer). The receipt is issued to the
entity specified in the source tuple of the subject bundle or the
source's designated alternate (report-to field), which would
typically be located on a different host. The return receipt uses
the same custodial delivery option setting used in the subject
bundle. (Return receipts are never issued with the return receipt
delivery option requested, to avoid "return receipt storms.")
- Forwarding Indication - sent by an agent when the last fragment
(in terms of time) of a bundle has been forwarded. The indication
is sent to the report-to destination if specified, and to the
source of the subject bundle otherwise
- Custody Transfer Indication - same as forwarding indication, but
sent when a custodial transfer has successfully completed
- Secured Delivery - indicates the application has provided
authentication material along with its message send request. To
operate under general circumstances, applications should be
prepared to supply authentication credentials and request secured
delivery. Local policy determines whether any bundles may be sent
lacking the security option, and regions beyond the originating
region may require security even if the originating region does
not.
3.3.3 Required Information
- Applications always specify the following information when requesting
to send data:
Cerf, et al. Expires April 2004 [Page 8]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
- Expiration Time - indicates the time at which the data is no longer
useful to the application. If a bundle is stored in the network
when its expiration time is reached, it may be discarded.
Expiration times are expressed as an offset relative to the current
time of day, which is assumed to be known by all DTN nodes
- Source Tuple - an identifying name of the sender
- Destination Tuple - an identifying name of the recipient
- Report-To Tuple - an identifying name of where reports (return-
receipt, route-tracing functions, etc.) should be sent. This will
often coincide with the Source Tuple.
- Receive-only applications need only specify a receiving tuple when
requesting to receive data.
3.4 Nodes and Agents
A DTN forwarding agent (or "agent" in this document) is an engine for
sending and receiving DTN messages (bundles). Agents are typically
programs (similar to mail transfer agents in e-mail systems) that
execute in a host environment. The execution environment for an
agent is called a DTN "node" and is typically a single computer. DTN
agents may act as sources, destinations, or forwarders of bundles. A
node may support more than one agent, although we do not believe this
configuration to be particularly common or desirable. Each agent is
uniquely identified by at least one tuple; an agent that is reachable
in multiple regions will have at least one identifying tuple for each
region in which it resides. Applications may be co-resident on a
node with the agent it uses for DTN communications, or they may be
separated (and use some private protocol other than bundling for the
agent-to-application communication).
Each bundle agent on a DTN node has a distinguishing name (distinct
from any applications *using* that agent). This is necessary for
generating custody acknowledgments to the agent itself rather than to
an application.
Cerf, et al. Expires April 2004 [Page 9]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
3.5 Regions and Gateways
The DTN architecture defines a "network of internets" comprised of
"DTN regions." Assignment of DTN agents to particular regions is an
administrative decision, and may be influenced by differences in
protocol families, connection dynamics, or administrative policies.
Regions may also be delimited based upon other criteria, such as
trust boundaries [NEWARCH] or global/local address partitions [IPNL,
TRIAD]. Each DTN region has a unique name that is known (or
knowable) among all regions of the DTN. Thus, a DTN-wide directory
for region names is required for inter-region operations.
Regions are key concepts in the DTN architecture. DTN bundles that
originate outside the destination region are first transmitted toward
one of the DTN gateways that connect the source region with one or
more other regions. Routing outside the destination region is based
on the destination region's name, and not on the completely formed
destination tuple (see below).
All inter-region message forwarding takes place between DTN agents
called *gateways*, which provide the interconnection points between
regions. These correspond to "waypoints" in [META], and to the
gateways described in the original ARPANET/Internet designs [CK74].
DTN gateways differ from ARPANET gateways because they operate above
the transport layer and are focused on message switching rather than
packet switching. However, both DTN gateways and ARPANET gateways
provide interoperability between the protocols specific to one region
and the protocols specific to another, and both provide a store-and-
forward forwarding service (with DTN gateways employing persistent
storage for its store and forward function).
The following list identifies the requirements for DTN regions:
- Each DTN region shall have an identifier space that is shared by
all DTN agents within the region. A region must specify the
naming conventions to be employed within that region for entity
identification.
- Each agent that is a member of the region shall have a unique
identifier drawn from that identifier space. (Note that for some
types of regions, a "node" may be made up of a collection of
computational elements, possibly geographically distributed. A
single unique identifier may collectively refer to them. Further,
the unique identifier requirement only applies to nodes that are
intended to *receive* data from other DTN nodes.)
- To be considered a member of a region, each prospective member of
the region shall have the ability to reach every other member of
the region without depending on any DTN nodes outside the region
using some protocol(s) known or knowable to each node. (Although
a DTN node may not necessarily be *directly* reachable. This may
Cerf, et al. Expires April 2004 [Page 10]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
require forwarding and/or store-and-forward operation by other DTN
nodes inside the same region.)
Cerf, et al. Expires April 2004 [Page 11]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
3.6 Tuples
The region name described above (plus some forwarding state) is
necessary and sufficient to route a bundle to its destination region,
but not to its final destination(s). The DTN architecture uses a
tuple comprised of the region name and a region-specific entity name
to identify a particular entity (or set of entities) in a DTN. The
entity name is *opaque* outside the region of definition, but must be
resolvable to one or more endpoints within its containing region. An
entity might be a host, a protocol, an application, some aggregate of
these, or something else depending on the nature of the addressing
and naming structures used in the containing region. We have adopted
a format based upon Universal Resource Identifiers (URIs) [RFC2396]
as the general (written) structure for tuples using the reserved URI
scheme name "bundles." A "fully-qualified" tuple is thus expressed
using the following convention:
bundles://<region-name>/<scheme>://<scheme-specific-entity-name>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(opaque portion: entity name)
This structure represents a nested URI. The <region-name> portion of
the tuple identifies a region name in some yet-to-be-specified global
namespace. The <scheme> identifier, which must be resolvable in the
region specified by <region-name>, specifies the semantics to be
applied to the <scheme-specific-entity-name> portion of the tuple. A
concrete example in an Internet-like region named "Earth.Internet"
might be the following:
bundles://Earth.Internet/tcp://venera.isi.edu:5000/243845
Here, "bundles" is the (proposed) reserved URI scheme name
[RFC2396]. The second-level scheme name identifies the scheme "tcp"
which implies a reliable connection (presumably using the TCP
protocol) should be used to contact a host specified by DNS name
"venera.isi.edu" at port 5000. Any data beyond this in the tuple not
required by the delivery semantics of the "tcp" scheme is given to
receiving applications. Clearly, some form of binding mechanism
(local to the containing region) is required to allow applications to
associate themselves with DTN tuples. The details of the binding
mechanism are region and API-specific and not discussed here.
However, any such mechanism must provide a way for a requesting
application to bind to a *prefix* of a fully qualified destination
tuple. This allows the system to support multiple receiving
applications associated with the same destination tuple.
Discovery of valid DTN region names and how to reach them is the
responsibility of bundle-layer routing (see below), which includes
both path selection and scheduling. This problem is presently an
area of active research. Knowing the destination name of a desired
Cerf, et al. Expires April 2004 [Page 12]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
communication peer (i.e. how to acquire the appropriate entity names
of a peer in a remote region) is out of the scope of this document,
but corresponds directly to the Internet problem of knowing port
numbers a-priori. An out-of-band mechanism is frequently used.
3.7 Late Binding
The opacity of entity names outside their local region enforces
another key concept in the DTN Architecture: that of late binding.
Late binding refers to the fact that the entity name of a tuple is
not interpreted (e.g., used to form an address for delivery within
the region) outside its local region. This avoids having a universal
name-to-address binding space (and its associated database and
synchronization issues).
This approach preserves a significant amount of autonomy within each
region. The entity names used in tuples might be built on URIs (as
illustrated above), or might look like "expressions of interest" or
forms of database-like queries as in a directed diffusion-routed
network [IGE00] or as in intentional naming [WSBL99].
Additionally, late binding avoids the delay-related issue that the
name/location binding information in a region might be highly
ephemeral relative to the transit time of a bundle. We assume that
the internal details of a destination region will be sufficiently
stable, at least for the duration of a message transit delay within
that region, or that delay-tolerant mechanisms will be employed
*within* the region to compensate. (This is, by definition, a local
issue within the region and may be accommodated in whatever manner is
most practical for that region.)
3.8 Routing
The bundle layer provides routing among DTN agents, including DTN
gateways. There may be many DTN gateways that interconnect adjacent
regions, and there may be multiple bundle routing "hops" within a
single region (especially if intra-regional connectivity is
intermittent).
Routes (choice of next hop bundle agent for each bundle and when to
send traffic to them) are computed based on a collection of
"contacts" that indicate the start time, duration, endpoints,
forwarding capacity and latency of a link in the topology graph.
They are generally assumed to be describing edges on a *directed,
time-varying, multi-graph*. (A multi-graph may have more than one
edge between the same two vertices). Contacts may be deterministic
and well-known, or may be derived from estimates and may therefore
contain errors (see below).
Note that for DTN routing, location of the next hop toward a
specified destination is not the only type of routing that may need
to be accomplished. In addition, a bundle requiring custody transfer
may need to be forwarded to a next hop toward a next custodian, and
Cerf, et al. Expires April 2004 [Page 13]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
this route may not coincide with the best next hop toward the
destination.
3.8.1 Types of Routes
DTNs may be required to function in the presence of various forms of
connectivity characterized by several "contact types":
Persistent Contacts
Persistent contacts are contacts that are always available, with no
connection establishment required. In the IP world, a Digital
Subscriber Line (DSL) or other "always-on" connection is an example.
OnDemand Contacts
OnDemand contacts are contacts that require some action in order to
instantiate, but otherwise function as persistent contacts until
terminated. Dial-up connections are an example of OnDemand contacts
(at least, from the viewpoint of the dialer; they may be viewed as an
Opportunistic Contact - below - from the viewpoint of the dial-up
service provider).
Intermittent - Scheduled Contacts
Scheduled contacts are those where there is an agreement to establish
a link between two points at a particular time, for a particular
duration. An example of a scheduled contact is a link that uses a
low-earth orbiting satellite. A schedule of view times, durations,
capacities and latencies can be constructed for each next-hop
neighbor reachable via the satellite.
Intermittent - Opportunistic Contacts
Opportunistic contacts are those that are not scheduled, but rather
present themselves unexpectedly and frequently arise due to node
mobility. For example, an opportunistic contact may arise with an
aircraft flying overhead (whose flight path is unknown) that beacons,
thereby advertising its availability for communication. Another type
of opportunistic contacts might be via an infrared or BlueTooth
communication link between a personal digital assistant (PDA) and a
kiosk in an airport concourse offering bundle service. As the PDA is
brought near the kiosk, and if its owner so authorizes, it could
advertise the owner's planned travel path and express a desire to
have contacts with subsequent kiosks along the path provided. This
information could be used by the collection of kiosks to form a set
of probable communication opportunities for which bundle transfers
can be scheduled. In such cases it may be profitable to consider
limited duplication or flooding in the network [VB00] to enhance the
likelihood of reliable delivery.
Intermittent - Predicted Contacts
Cerf, et al. Expires April 2004 [Page 14]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
Predicted contacts are those based not on a fixed schedule, but
rather on statistical inference of likely contact times and durations
derived from a history of previously observed contacts or other
information. Given a great enough certainty that a predicted contact
will occur, a DTN agent may allocate (schedule) bundles to that
predicted contact that would otherwise be allocated to different
contacts. In the previous example, the probable contacts in the
airport concourse would result in the establishment of a set of
predicted contacts of a given duration (perhaps based on the PDA
owner's walking speed and the kiosk's coverage area). The PDA could
decide how to use those contacts for scheduling outgoing bundles.
The algorithms for establishing the predicted time and duration of a
contact, the degree of uncertainty in those estimates, the time at
which to abandon the wait for a predicted contact, and the guidelines
for allocating bundles to such contacts are all open research areas.
3.8.2 Bundle Storage for Store-and-Forward operation
While IP networks are based on "store-and-forward" operation, there
is an assumption that the "storing" will not persist for more than a
small amount of time (usually equal to the queuing and transmission
delay). In contrast, the DTN architecture does not expect that an
outbound link will be available when a bundle is received, and
expects to store that bundle for some time until a link does become
available. We anticipate that most DTN agents will use some form of
persistent storage for this -- disk, flash memory, etc., and that
stored bundles will survive system restarts.
All DTN agents, even those that do not provide custodial operations
as described in section 3.10, must be able to queue bundles until
outbound contacts are available. Each DTN agent that is also willing
to provide custody transfer operations should provision for longer-
term storage of bundles, committing to store bundles for which it
takes custody for the entire remainder of their lifetimes, if
necessary.
It is entirely possible that an agent will need to "take a break"
from agreeing to new custody transfers while it completes pending
custodial transfers and recovers persistent storage. Two mechanisms
support this: First, the node can simply forward incoming bundles
without taking custody. The fact that a node is a potential
custodian is no guarantee that it will actually take custody of any
given bundle that is routed to it. Second, the node can indicate to
others it is no longer willing to take custody for future messages.
Once other nodes become informed of this information, they can
potentially seek an alternative custodian.
The availability of long-term storage for bundles allows the next-hop
forwarding decision to potentially be modified prior to transmission.
In particular, if a future contact is chosen to carry a bundle and
some other superior contact becomes known, the bundle could be re-
Cerf, et al. Expires April 2004 [Page 15]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
assigned. Details of this re-assignment operation are local to a
particular bundle router and influenced by the times at which contact
schedules become known.
3.9 Bundle Fragmentation and Reassembly
There are two forms of bundle fragmentation/reassembly. The first
form corresponds closely to traditional IP fragmentation, while the
second form is novel. In either case the *final destination(s)* are
responsible for reassembling fragments of a bundle into the original:
Any DTN agent may -proactively- choose to divide a bundle into
multiple self-identifying smaller parts and transmit each such
part as a bundle. This form of fragmentation is analogous to IP
fragmentation.
A bundle agent may -reactively- choose to fragment a bundle on
receipt. This situation arises when a portion of a bundle may
have been received successfully. In this case, the receiving node
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
optimistically continue sending the remaining portion of the
original bundle when subsequent contacts become available.
Reactive fragmentation is specifically designed to handle cases in
which a router is faced with forwarding a bundle for which no
single contact provides sufficient data transfer volume.
Cerf, et al. Expires April 2004 [Page 16]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
3.10 Bundle Layer Reliability and Custody Transfer
The bundle layer provides an end-to-end reliable message delivery
service that employs in-network reliability mechanisms between
(possibly non-network-layer-adjacent) DTN nodes. The bundle layer
makes use of the reliability mechanisms available from the underlying
transport layers of each region, and a single bundle-layer hop *may*
span an entire region. The bundle layer supports end-to-end
reliability derived solely from the custody transfer mechanism, but
also provides a true (optional) end-to-end acknowledgement for
application use. Applications wishing to utilize this indication for
their own end-to-end bundle retransmission mechanisms are free to do
so.
The bundle layer provides three types of delivery services, with
various levels of reliability-enhancing mechanisms: end-to-end
acknowledgment of a bundle, custodial transmission (with in-network
retransmission if required), and unacknowledged bundle transmission.
Custody transfer allows the source to delegate retransmission
responsibility and recover its retransmission-related resources
relatively soon after sending the bundle (on the order of a round-
trip time to the first bundle hop). While not every node in a DTN
must be capable of providing custodial services, all DTN nodes that
span networks that may be frequently disconnected are expected to be
able to be custodians.
3.11 Time Synchronization
The DTN architecture depends on time synchronization (supported by
external, region-local protocols) for two primary purposes: routing
with scheduled or predicted contacts and bundle expiration time
computations. Routing based on schedules and dependent upon
coordination of shared assets (such as directional antennas) may
create other operational requirement for time synchronization to
achieve contact rendezvous.
Bundle expiration is achieved by including a source time stamp and an
explicit expiration field (in time units after the time in the source
time stamp) in each bundle header. Its sole use by the bundling
layer is for purging data from the network, so the synchronization
requirements posed here are not strict. This approach allows a
source time stamp to be used for a number of purposes, such as unique
identification of individual messages from a particular source. The
source timestamp on an arriving bundle is made available to consuming
applications by an API (specified elsewhere). DTN nodes must ensure
that timestamps in bundles they send never decrease. This should not
pose too burdensome a requirement---the current specification for the
timestamp is 64 bits and includes a 32-bit quantity to count
microseconds.
Cerf, et al. Expires April 2004 [Page 17]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
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,
and its relationship to routing and 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 notion of flow control may be hop-by-hop among
agents, rather than only end-to-end). 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. If flow control is propagated backward from destination nodes
to routers and eventually back to traffic sources, then flow control
can be at least a partial solution to the problem of congestion as
well.
One view of congestion control is as follows: "Congestion control is
concerned with allocating the resources in a network such that the
network can operate at an acceptable performance level when the
demand exceeds or is near the capacity of the network resources.
These resources include bandwidths of links, buffer space (memory),
and processing capacity at intermediate nodes. Congestion occurs
when the demand is greater than the available resources." [J90]
In a DTN, the likelihood of congestion occurring may vary widely
based upon routing selections. If the routing process is provided a
great deal of knowledge about contacts and traffic demands (and it
employs a reservation scheme), it may be able to arrange for traffic
to be sent so as to completely avoid congestion. If the routing
process is only permitted to know a subset of this information (or
the information provided to it is incorrect), data loss due to
congestion may occur. In most cases, we expect DTN flow control
decisions will be made locally to each agent based on a combination
of global (that might be stale) and local knowledge regarding the
topology, available buffers, and traffic demand. However, the bundle
layer *might* be able to delegate the implementation of those
decisions to the underlying transport protocols, as follows.
For purposes of discussing flow control, we have not yet considered
multipoint communication at or below the bundle layer, so each
individual flow control problem involves just two nodes. Because
inter-region traffic must pass through inter-region gateways, any two
nodes between which flow control is an issue must inhabit a common
DTN region and be using a common transport protocol below the bundle
layer (otherwise they could not be communicating and there would be
Cerf, et al. Expires April 2004 [Page 18]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
no flow to control). Therefore, it may be possible to accomplish DTN
flow control by invoking whatever flow control mechanisms are already
provided within the region by the common transport protocol, if such
mechanisms exist.
Alternatively, a new, supplementary flow control protocol could be
developed at the bundling layer; this would have the advantage of
reducing a DTN's reliance on capabilities provided by the underlying
protocols and may be required anyhow for environments where the
region-specific transport protocol(s) lack flow control. At this
time it's still unclear which approach is preferable, and some
combination of the two may eventually be declared to be the best
choice.
In either approach, the problem of flow control between nodes
separated by very large signal propagation times remains to be
solved: TCP's flow control and congestion control facilities could be
leveraged within regions characterized by small round-trip times, but
at this time no comparable protocol exists for very long delay paths.
It remains as an exercise for us to demonstrate that a hop-by-hop
flow control scheme in long and/or highly variable delay environments
can effect end-to-end congestion control in a fair and efficient
manner.
3.13 Security
Resource scarcity in delay-tolerant networks dictates that some form
of access control to the network itself is required in many
circumstances. It is not acceptable for an unauthorized user to be
able to easily flood the network with traffic, possibly preventing
the network's mission from being accomplished. Implicit in this
statement is a requirement for some form of admission control and/or
in-network authentication and access control that is sensitive to the
class of service that a user has requested. In a low delay
environment, performing such computations would be tedious for
performance reasons. In a high/variable delay, and possibly low data
rate environment, it is problematic for other reasons: remote access
control lists are difficult to update, query/response key
distribution protocols are not resource-efficient, and routers or end
nodes might be compromised for significant periods of time before
being noticed.
To implement a security model with infrastructure protection, each
message includes an immutable signature containing a verifiable
identity of the sender (or role), and other conventional
cryptographic material to verify accuracy of the message content.
Agents check these authentication credentials at each DTN hop, and
discard traffic as early as possible if authentication or access
control checks fail. This approach has the associated benefit of
making denial-of-service attacks relatively harder to mount (as
compared with conventional Internet routers). However, the obvious
cost is the considerably larger computation and storage overhead
required at each DTN node.
Cerf, et al. Expires April 2004 [Page 19]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
The current approach uses asymmetric cryptography as a starting point
for keying, and requires one or more trusted credential-issuing
authorities. Each agent is issued initial configuration information
usable to assess the validity of credentials they will be presented
with in the future (e.g. a certificate authority's public key, or IBE
system parameters [BF01]). An agent sending a message must obtain a
verifiable copy of its public information from an authority known to
other DTN agents (i.e. that corresponds to the initial configuration
information other agents have been equipped with). An application
then presents a copy of its verifiable public information along with
a message to be carried signed appropriately using her private
information. At the first DTN agent, the public information is
verified to validate the sender and requested CoS against an access
control list stored with the agent. Accepted messages are then re-
signed using the private information of the router itself for
transit.
Using this approach, only "first-hop" agents need cache per-user
information, and then only for adjacent users. Non-edge "core" agents
can rely on the authentication of their upstream neighbors to verify
the authenticity of messages. We believe this approach will help to
improve the scalability of key management for these networks, as it
will limit the number of cached public credentials to a function of
the number of adjacent nodes rather than the number of end-users.
This should provide both the obvious advantage of space savings, but
also an improvement to system management as router keys are expected
to be changed less frequently than end-user keys. As DTNs are likely
to be deployed in remote areas, re-keying operations may be
comparatively burdensome system management tasks, so limiting the
number and frequency of certificate updates should provide additional
savings.
The approach described above is partially susceptible to compromised
agents. If an otherwise-legitimate agent is compromised, it would be
able to utilize network resources at an arbitrary CoS setting and
send traffic purportedly originating from any user who's identity is
known to the router. However, if message signatures are applied using
user-provided keys at endpoints and carried end-to-end (an option for
DTN security), a legitimate user could repudiate the origin of any
traffic generated in this manner. Thus, we believe a reasonable
trade-off is to admit the possibility that a compromised router could
launch a denial-of-service attack in order to gain the scalability
benefits of not checking end-user credentials at every hop.
4 State Management Considerations
An important aspect of any networking architecture is its management
of state information. This section describes the state information
that is managed at the bundle layer and discusses the conditions
under which that state information is established and how it is
removed.
Cerf, et al. Expires April 2004 [Page 20]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
4.1 Demultiplexing and Binding State
In long/variable delay environments, an asynchronous application
interface seems to be the only sensible approach. Such interfaces
involve callback registration actions that create state information.
This information is typically created by explicit request of the
application, and is removed by a separate explicit request, and is
thus "hard" state. In most cases, there must be a provision for
retaining this state information across application and system
restart because a client/server message round-trip time may exceed
the requesting application's execution time (or node's uptime).
In addition, the tuples for which an application wishes to receive
data may incorporate entity names that are associatively-mapped (e.g.
have properties in common with URNs [RFC2276]). That is, these names
may need to be registered and resolved within a region using some
directory service that provides an extra level of indirection (e.g.
dynamic DNS [RFC2136]), and consequently may involve the
establishment, maintenance, and tear-down of state dependent on the
particular choice of indirection infrastructure.
4.2 Bundle Retransmission State
State information to support bundle retransmission is created by a
DTN agent when a bundle is received from a DTN application requesting
custodial transmission or when a bundle is received from a peer DTN
agent and the receiver intends to assume custody of the bundle. The
bundle's expiration field (possibly mitigated by local policy)
determines when this state is purged from the system in the event
that it is not purged explicitly due to acknowledgment.
4.3 Bundle Routing State
Forwarding and routing tables, whether statically configured or
maintained by routing protocols, introduce state information that
must be managed in a manner that is dependent upon the specific
routing mechanisms employed. While routing protocols have not yet
been developed for DTN networks, in order to provide forwarding, a
DTN agent will be required to have available a forwarding table
containing next-hops indexed by region names (and also conceivably by
entity names for intra-region routing). In addition, as mentioned
above, it seems highly useful to also include a method for agents to
learn about potential custodians. This information would enlarge the
overall forwarding state, but probably not significantly.
We have not yet seriously considered the routing protocols or metrics
that we will use, so we do not have an estimate for the size of each
routing entry, whether it is for inter-region or intra-region
routing. This remains as future work.
Cerf, et al. Expires April 2004 [Page 21]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
4.4 Security-Related State
The infrastructure protection model described in this architecture
requires maintenance of state in all DTN nodes. All agents are
required to store their own private keys and a block of information
used to verify credentials issued by an agreed-upon set of
authorities. Further, in most cases, DTN nodes will cache the public
information (and possibly the credentials) of their next-hop (bundle)
neighbors. All keys will have expiration times, and agents are
responsible for acquiring and distributing newly-generated copies of
their public information prior to the expiration of the old set (in
order to avoid a disruption in network service).
While the keying is used for authentication, access control lists
represent another block of state present in any node that wishes to
enforce security restrictions. The access control lists will
presumably be of small size for core nodes, as they should only need
to verify messages from their neighbors. Edge nodes, however, will
likely have access control lists that scale as the number of users
served by the agent in question.
Some DTNs may implement security "boundaries" at various points in
the network, where end-user credentials are checked in addition to
checking agent credentials (at the cost of additional storage
requirements). User-level public information will typically be
cached at these points in the network.
As with routing, the security approach is under development, so the
exact enumeration of the required state will depend on the particular
algorithms eventually selected for implementation.
5 Bundle Header Information
The bundle layer must carry some information end-to-end. The full
details of the fields present in a bundle header are specified in
[BundleSpec]. This section documents the meta-data information that
must be carried end-to-end, and notes which of those data elements
may be supplied by the application using the bundle service.
* Version Identifier: an 8-bit bundle protocol
* Destination: a variable-length field containing the destination
tuple, as described above. It is supplied by the local
application when sending using the bundle service.
* Source: this is also a variable-length field containing the
identifier of the source tuple. It is supplied by the
requesting application, possibly based upon knowledge provided
by its local agent. Employing information provided by the local
agent is useful because a particular agent may have multiple
bundle interface names and one may be chosen based on routing
decisions or other criteria.
* Report-to (optional): a source may anticipate not being able to
accept replies or diagnostic reports, and may use the report-to
Cerf, et al. Expires April 2004 [Page 22]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
tuple to specify the destination for such receipts and
diagnostics.
* Current custodian (optional): Tuple identifying the current
custodian. It is necessary to identify the upstream node that
currently has custody of a bundle, in order to acknowledge
correct receipt or custody transfer of a bundle or bundle
fragments.
* Class of service flags:
- Flags: custody, return receipt, delivery record
- CoS Selector: bulk, normal, expedited
- Security: presence of authentication and/or encryption
* Send timestamp: the time that a bundle was presented by the
sending application to the bundle layer for transmission.
Timestamps use microsecond-level granularity.
* Expiration: an offset, in seconds, from the send timestamp that
indicates when the bundle shall be purged from the DTN.
* Authentication information (optional): authentication data used
to prove that this bundle should be forwarded in the network.
* Fragmentation information (optional): for a bundle fragment,
indicates the place in the original bundle this fragment
belongs.
Some bundles (or events) cause a status indication to be generated by
the bundle layer. Bundle layer indications are sent as bundles with
the user data portion replaced by a Status Report, consisting of the
following information:
* Source tuple of the subject bundle: a copy of the source tuple
from the subject bundle.
* Send timestamp of the subject bundle: used to disambiguate
status reports for different bundles from the same source entity
* Status flags, indicating whether or not a bundle was:
. received correctly by the sender of the Status Report
. Custodially transferred to the sender of the Status Report
. Forwarded by the sender of the Status Report
* Time of Receipt (optional): the time at which the sender of the
Status Report received the bundle.
* Time of Forward (optional): the time at which the sender of the
Status Report forwarded the bundle
6 Application Structuring Issues
DTN bundle delivery is intended to operate in a *delay-tolerant*
fashion over a broad range of network types. That does not mean that
there *must* be delays in the network, but that there *may* be very
significant delays (including extended periods of disconnection
between sender and intended recipient). The protocols providing the
services exposed by the bundle layer are delay tolerant, so to take
best advantage of them, applications using them should be, too.
Message-oriented communication differs from conversational
communication. In general, applications should attempt to include
enough information in a bundle so that it may be treated as an
Cerf, et al. Expires April 2004 [Page 23]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
independent unit of work by the remote entity (a form of "application
data unit" [CT90] or "transaction", although transactions carry
connotations of multi-phase commitment that we do not intend here,
but see [FHM03] for more discussion). The goal is to minimize
conversation between applications that are separated by a network
that presents long and possibly highly variable delays, and to
constrain any conversation that does occur to be asynchronous in
nature. A single file transfer request bundle, for example, might
include authentication information, file location information, and
requested file operation. Comparing this style of operation to a
classic FTP transfer, one sees that the bundled model can complete in
one round trip time, 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. Applications
may terminate (voluntarily or not) between the time that a bundle is
sent and the time its response is received. If an application has
anticipated this possibility, it is possible to re-instantiate the
application 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.
7 Convergence Layer Considerations for Use of Underlying Protocols
Implementation experience with the DTN architecture has revealed an
important architectural construct and implementation methodology for
DTN agents. Not all transport protocols in different protocol
families provide the same exact functionality, so some additional
adaptation or augmentation on a per-stack basis may be required to
provide the reliable delivery the bundle layer expects. This
adaptation is accomplished by a set of "convergence layers" placed
between the bundle layer and underlying (transport) protocols. The
convergence layers manage the protocol-specific details of
interfacing with a particular transport service and present a
consistent interface to the bundle layer.
The complexity of a convergence layer may vary substantially
depending on the type of protocol stack it adapts. For example, a
TCP/IP convergence layer for use in the Internet might only have to
add message boundaries to TCP streams (an SCTP convergence layer
might be less complex), whereas a convergence layer for some network
where no reliable transport protocol exists may have a considerable
amount of work to do, at least if custody transfer is to be
supported. The issues with implementing the bundle layer on top of
unreliable regional transport protocols remains to be explored.
Cerf, et al. Expires April 2004 [Page 24]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
8 Summary
The DTN architecture addresses many of the problems exhibited by
networks operating in environments subject to poor performance and
non-continuous end-to-end connectivity. It is based on asynchronous
store-and-forward 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
reliability with end-to-end acknowledgements 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 emerging (and existing) networks that have, until
recently, operated independently and isolated from each other. In
subsequent documents, we intend to specify profiles of this
architecture that address several specific environments in detail.
9 Informative References
[B03] S. Burleigh et al, "Delay-Tolerant Networking: An Approach to
Interplanetary Internet," IEEE Communications Magazine, June 2003.
[CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a
new generation of protocols," Proc. SIGCOMM 1990.
[W03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial",
Wartham Associates, Available from http://www.dtnrg.org
[F03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged
Internets," Intel Research, Proceedings SIGCOMM, Aug 2003.
[IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed
Diffusion: A scalable and robust communication paradigm for
sensor networks", MobiCOM 2000, Aug 2000.
[WSBL99] W. Adjie-Winot, E. Schwartz, H. Balakrishnan, J. Lilley,
"The design and implementation of an intentional naming system",
Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999.
[NEWARCH] NewArch Project: Future-Generation Internet Architecture.
Home page: http://www.isi.edu/newarch
[META] J. Wroclawski, "The Metanet," Workshop on Research Directions
for the Next Generation Internet", May 1997. Available from
http://www.cra.org/Policy/NGI/papers/wroklawWP.
[CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network
Intercommunication", IEEE Trans. on Comm., COM-22(5), May 1974
Cerf, et al. Expires April 2004 [Page 25]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
[DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard
Internet Suite for the Interplanetary Internet?", MITRE White Paper,
http://www.ipnsig.org/reports/TCP-IP.pdf
[J90] R. Jain, "Congestion Control in Computer Networks: Issues and
Trends," IEEE Network Magazine, May 1990.
[RFC2136] P. Vixie, ed., "Dynamic Updates in the Domain Name System
(DNS UPDATE)," Internet Request for Comments, RFC2136, Apr. 1997
[BundleSpec] S. Burleigh, et al, "Bundle Protocol Specification" work
in progress, (draft-irtf-dtnrg-bundle-spec-01.txt), October 2003.
Available from http://www.dtnrg.org.
[RFC2396] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
Identifiers (URI): Generic Syntax", Internet RFC 2396, Aug 1998
[VB00] A. Vahdat, D. Becker, "Epidemic routing for partially-
connected ad hoc networks", Duke Tech Report CS-200006", Apr. 2000
[IPNL] P. Francis, "IPNL: A NAT-Extended Internet Architecture",
Proceedings SIGCOMM, Aug 2001.
[TRIAD] D. Cheriton, M. Gritter, "TRIAD: A New Next-Generation
Internet Architecture", Available from
http://www.dsg.stanford.edu/triad/index.html
[BF01] D. Boneh, M. Franklin, "Identity based encryption from the
Weil pairing", SIAM J. of Computing, 32(3), 2003
[FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable
Delivery in Delay Tolerant Networks", Available from
http://www.dtnrg.org
[RFC2276] K. Sollins, "Architectural Principles of Uniform Resource
Name Resolution", Internet RFC 2276, Jan 1998
10 Security Considerations
Security is an integral concern of the Delay Tolerant Network
Architecture. Section 3.13 of this document presents an approach for
securing the DTN architecture. These capabilities may also be useful
in providing facilities to DTN applications to construct their own
end-to-end security protocols.
Cerf, et al. Expires April 2004 [Page 26]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
11 Authors' Addresses
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
1820 Dolley Madison Blvd.
M/S W650
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-research.net
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
1820 Dolley Madison Blvd.
M/S W650
McLean, VA 22102
Telephone +1 (703) 883-6547
Cerf, et al. Expires April 2004 [Page 27]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
FAX +1 (703) 883-7142
Email kscott@mitre.org
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.
12 Intellectual Property Notices
The IETF takes no position regarding the validity or scope of
any intellectual property 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; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to rights
in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication 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 implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
13 Copyright Notices
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and
Cerf, et al. Expires April 2004 [Page 28]
Internet Draft draft-irtf-dtnrg-arch-01.txt October 2003
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implmentation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Cerf, et al. Expires April 2004 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-24 08:48:58 |