One document matched: draft-irtf-dtnrg-arch-02.txt
Differences from draft-irtf-dtnrg-arch-01.txt
DTNRG Chair
DTN Research Group V. Cerf
INTERNET-DRAFT MCI/Jet Propulsion Laboratory
<draft-irtf-dtnrg-arch-02.txt> S. Burleigh
July 2004 A. Hooke
Expires January 2005 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, we certify that any applicable
patent or other IPR claims of which we am aware have been disclosed,
and any of which we become aware will be disclosed, in accordance
with RFC 3668.
This document is an Internet-Draft and is in full conformance with
Sections 5 and 6 of RFC3667 and Section 5 of RFC3668.
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). See http://www.dtnrg.org for more
information.
Abstract
This document describes an architecture for delay-tolerant networks,
and is a generalization of the architecture originally designed for
the Interplanetary Internet: a communication system to provide
Internet-like services across interplanetary distances in support of
deep space exploration. This document describes a generalization of
this architecture that addresses a variety of internetworks with
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 layer of the networks on which it is hosted. The
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
document presents an architectural overview followed by discussions
of services, topology, routing, security, reliability and state
management.
Cerf, et al. Expires January 2005 [Page 2]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
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?...........5
3 DTN Architectural Description................................6
3.1 The DTN Architecture is Based on Virtual Message Switching
........................................................6
3.2 DTN Classes of Service Mimic Postal Operation...........7
3.3 DTN Postal-Style Delivery Options.......................8
3.4 Nodes and Applications..................................9
3.5 Regions................................................10
3.6 Endpoint Identifiers (Endpoint IDs)....................11
3.7 Late Binding...........................................11
3.8 Routing and Forwarding.................................11
3.9 Fragmentation and Reassembly...........................13
3.10 Reliability and Custody Transfer.......................13
3.11 Time Stamps and Time Synchronization...................13
3.12 Congestion and Flow Control at the Bundle Layer........14
3.13 Security...............................................15
4 State Management Considerations.............................16
4.1 Registration State.....................................16
4.2 Custody Transfer State.................................17
4.3 Bundle Routing and Forwarding State....................17
4.4 Security-Related State.................................17
5 Application Structuring Issues..............................18
6 Convergence Layer Considerations for Use of Underlying
Protocols...................................................19
7 Summary.....................................................19
8 Security Considerations.....................................20
9 IANA Considerations.........................................20
10 Normative References........................................20
11 Informative References......................................20
Cerf, et al. Expires January 2005 [Page 3]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
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, 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.
-Removed list of bundle header information as it will be contained in
the protocol specification document.
Cerf, et al. Expires January 2005 [Page 4]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
1 Introduction
This document describes an 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
[SB03] for more details). Other networks to which we believe this
architecture applies 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 [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] and [JFP04].
We define an end-to-end message-oriented overlay called the "bundle
layer" that exists at a layer above the transport layers of the
networks on which it is hosted and below applications. This overlay
employs persistent storage at intermediate nodes (DTN routers),
includes a hop-by-hop transfer of reliable delivery responsibility
and optional end-to-end acknowledgement. For interoperability, it
includes a flexible naming scheme (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. In a sense, it represents a
networking architecture among application-layer gateways or proxies
that employ store-and-forward message routing to overcome
communication disruptions.
Nodes unable to support the full capabilities required by this
architecture may be supported by application layer proxies, acting as
DTN applications. In particular, the DTN naming scheme is able to
carry endpoint identifiers in an opaque fashion, thereby supporting
references to non-DTN capable endpoints where required.
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,DFS02].
The existing Internet Protocols do not work well for some
environments, due to some fundamental assumptions built into the
Internet architecture:
Cerf, et al. Expires January 2005 [Page 5]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
- 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 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
In light of these issues, the DTN architecture is conceived based on
a number of design principles that are summarized here (and further
discussed in [KF03], as mentioned above):
- provide a coarse-grained class of service and delivery options
based on 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 store-and-forward
operation over potentially long timescales (i.e. to support
operation in environments where no end-to-end path may ever exist)
- provide security mechanisms that protect the infrastructure from
unauthorized use
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 design decisions that result from those design
principles.
3.1 The DTN Architecture is Based on Virtual Message Switching
A DTN-enabled application transmits application-layer messages of
arbitrary length (subject to any implementation limitations). Their
relative order 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 an atomic fashion, although bundles may be split up
during transmission. Message senders and recipients are identified
by (variable-length) endpoint identifiers (described below). Bundles
may also contain an optional "report-to" endpoint identifier used
when special operations are requested to direct diagnostic output to
an entity other than the sender.
A message-oriented abstraction provides the bundle layer with a-
priori knowledge of the size and performance requirements of
Cerf, et al. Expires January 2005 [Page 6]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
requested data transfers. When there is a significant amount of
queuing that can occur prior to transmission over an outbound route
(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 decisions [JFP04]. 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 apply
scheduling and buffer management to entire units of data that are
useful to applications.
3.2 DTN Classes of Service Mimic Postal Operation
The (U.S. or similar) Postal Service provides a strong metaphor for
the services offered by a delay-tolerant network. 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 and security.
The DTN architecture, like most postal services, offers *relative*
measures of priority (low, medium, high) for carrying traffic. It
may also offer basic notifications, 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
transmitted."
An essential element of the postal service 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.
We have currently defined three relative classes of service in the
DTN architecture. The class of service for a bundle implies some
relative scheduling prioritization among bundles headed for the same
next hop at a router:
- Bulk - Bulk bundles are shipped on a "best effort" basis. No
bundles of this class will be shipped until all bundles of other
classes bound for the same next hop destination have been shipped.
- Normal - Normal class bundles are shipped prior to any bulk class
bundles.
Cerf, et al. Expires January 2005 [Page 7]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
- 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 (in full or in part) before expedited bundles bound.
Applications specify their requested class of service. This request,
coupled with policy applied at DTN routers, affects the overall
likelihood and timeliness of message delivery.
3.3 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 DTN 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 endpoint ID of the subject bundle or the
designated alternate (report-to field) if present. This provides
the ability to collect diagnostic information at locations other
than the sender. 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 a DTN router 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 endpoint ID 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 portions of the network beyond
Cerf, et al. Expires January 2005 [Page 8]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
the originating portion may require security even if the
originating portion does not.
- Applications always specify the following information when sending a
message:
- Expiration Time ¡ indicates the time at which the message is no
longer useful. 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 (also see time
synchronization, below)
- Source Endpoint ID ¡ an identifying name of the (original) sender
- Destination Endpoint ID ¡ an identifying name of the final intended
recipient
- Report-To Endpoint ID ¡ an identifying name of where reports
(return-receipt, route-tracing functions) should be sent. If not
present, reports are sent to the Source Endpoint ID.
3.4 Nodes and Applications
A DTN node (or simply "node" in this document) is an engine for
sending and receiving bundles. Applications utilize DTN nodes to
send or receive messages carried in bundles (or act as report-to
destinations for diagnostic information carried in bundles).
Applications utilize DTN nodes to bind to Endpoint IDs. Each
Endpoint ID contains a region naming portion (see below) and an
administrative naming portion, denoted in aggregate as {R, A}. In
addition, each node is uniquely identified by at least one Management
Endpoint ID (MEI). A DTN node is said to be "in" a region R1 if at
least one of its MEIs contains a region naming portion R such that
R=R1. MEIs are necessary for generating custody acknowledgments to
the bundle layer itself and for other administrative purposes.
An application may attempt to use a node to bind to arbitrary
Endpoint IDs, but attempts may fail. For example, if an application
attempts to bind to an Endpoint ID containing a region that the node
is not in, the attempt will likely fail.
Cerf, et al. Expires January 2005 [Page 9]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
3.5 Regions
The DTN architecture defines a "network of internets" comprised of
"DTN regions." Placing a DTN node in a particular region 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 (the R of the {R, A}
above).
DTN routers are somewhat similar to the gateways described in the
original ARPANET/Internet designs [CK74]. They differ from ARPANET
gateways because they operate above the transport layer and are
focused on virtual message forwarding rather than packet switching.
However, both DTN routers and ARPANET gateways generally provide
interoperability between underlying protocols specific to one
environment and the protocols specific to another, and both provide a
store-and-forward forwarding service (with DTN routers employing
persistent storage for their store and forward function).
Regions are a key concept in the DTN architecture. They provide a
separation of name spaces, and may be useful for partitioning routing
information or applying specific policies.
The following list identifies the requirements for DTN regions and
nodes within them:
1. Each DTN region shall have an identifier space (the A portion of
the {R, A} Entity ID above) that is allocated among all DTN nodes
within the region.
2. Each node in a region R1 is free to interpret the administrative
portion A for Endpoint IDs of the form {R1, A} in making routing
and/or policy decisions. Furthermore, any node not in R1 must treat
A as "opaque" (i.e. it cannot interpret A).
3. Every node in a region R1 shall have the ability to eventually
deliver messages to every other node in R1 (possibly through the
use of intermediate forwarding nodes)
Using these rules, significant flexibility is attained in the
structuring of administrative identifiers. They might, for example,
be built on DNS names, or URIs, 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].
Cerf, et al. Expires January 2005 [Page 10]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
3.6 Endpoint Identifiers (Endpoint IDs)
An Endpoint Identifier comprises two portions: a region identifier
and administrative naming portion, denoted {R, A}. Regions are named
by applications using syntax identical to that used in the domain
name system (DNS). (That is, hierarchical tree structure, dot-
separated text node names, left to right progress from leaf to root,
sibling nodes must have different names.)
3.7 Late Binding
The term binding here means interpreting the administrative
identifier A in {R, A} for the purpose of forwarding the associated
message to {R, A}. Late binding means that this interpretation is
not performed until the message reaches a node in region R, per rule
2 of section 3.5.
In a disconnected network, late binding may be advantageous because
the transit time of a message may exceed the validity time of a
binding. In addition, it may help to reduce loading in the network
by limiting the scope of binding meta-data propagation (e.g., DNS
zone transfers).
3.8 Routing and Forwarding
The DTN architecture provides a framework for routing and forwarding
among DTN nodes. Interconnections among DTN nodes can be described
with a *directed, time-varying* graph, as communication capabilities
cannot be assumed to be symmetric with respect to performance or
time. An edge in this graph represents a communication relationship
between two DTN nodes, typically based on a shared interconnection
technology. The performance characteristics of an edge may vary over
time. Estimates of these characteristics are represented by
"contacts" that indicate the anticipated performance (e.g. latency,
and forwarding capacity of that edge) over time. A route is a
sequence of edge choices used for transferring messages through the
topology graph.
3.8.1 Types of Contacts
DTNs may be required to function in the presence of any or all of the
following types of contacts:
Persistent Contacts
Persistent contacts are always available (i.e., no DTN action is
required to initiate a persistent contact). DTN protocols operating
over a Digital Subscriber Line (DSL) or other "always-on" connection
would be an example.
On-Demand Contacts
Cerf, et al. Expires January 2005 [Page 11]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
On-Demand contacts require some DTN action in order to instantiate,
but then function as persistent contacts until terminated. A dial-up
connection is an example of an On-Demand contact (at least, from the
viewpoint of the dialer; it may be viewed as an Opportunistic Contact
¡ below ¡ from the viewpoint of the dial-up service provider).
Intermittent - Scheduled Contacts
A scheduled contact is an agreement to establish a link between two
points at a particular time, for a particular duration. An example
of an edge with scheduled contacts is a link that uses a low-earth
orbiting relay satellite. The edge's list of contacts can be
constructed from the satellite's schedule of view times, capacities
and latencies.
Intermittent - Opportunistic Contacts
Opportunistic contacts are not scheduled, but rather present
themselves unexpectedly. For example, an aircraft flying overhead
and beaconing, advertising its availability for communication would
present an opportunistic contact eligible to carry bundles. 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 indefinite 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. Given a great enough confidence in
a predicted contact, routes may be chosen based on this information.
An Example
A PDA receiving GSM/GPRS data service in an airport concourse comes
into contact with a kiosk via BlueTooth communication, forming an
opportunistic contact. During this contact, knowledge of the
geography of the concourse and the mobility pattern of the PDA is
used to compute probable future contacts with other kiosks (perhaps
based on the PDA owner's walking speed and the kiosks' coverage
areas). The PDA is then free to use both the GPRS data service (a
persistent contact) and the predicted set of kiosk contacts to
deliver its waiting bundles according to the user's personal
optimization criteria. The user's criteria might be sensitive to
bandwidth, latency, cost, or other factors.
3.8.2 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
modest amount of queuing and transmission delay. In contrast, the
Cerf, et al. Expires January 2005 [Page 12]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
DTN architecture does not expect that outbound links are always
available, and instead expects to store received 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.
The availability of persistent storage allows the next-hop forwarding
decision to potentially be modified prior to transmission. In
particular, if a future contact is chosen for routing and some other
superior contact becomes known, the routing decision could be
changed.
3.9 Fragmentation and Reassembly
DTN fragmentation and reassembly is designed to improve the
efficiency of message transfers by ensuring that contacts 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 message. In this case the *final destination(s)* are
responsible for extracting the smaller blocks from incoming
messages and reassembling them into the original large block.
DTN nodes sharing an edge may -reactively- fragment a message
cooperatively when a message is only partially transferred. In
this case, the receiving node modifies the incoming message to
indicate it is a fragment, and forwards it normally. The previous-
hop sender may learn that only a portion of the message was
delivered to the next hop, and send the remaining portion when
subsequent contacts become available.
3.10 Reliability and Custody Transfer
The bundle layer provides unacknowledged, best-effort message
delivery. It also provides two options for enhancing delivery
reliability: end-to-end acknowledgment and custodial transmission
(with DTN retransmission if required). Applications wishing to
implement their own end-to-end message retransmission mechanisms are
free to utilize the acknowledgment.
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). Not all nodes in a DTN are
required by the DTN architecture to accept custody transfers. In
particular, some nodes may have sufficient storage resources to
sometimes act as custodians, but may elect to not offer such services
when congested.
3.11 Time Stamps and Time Synchronization
Cerf, et al. Expires January 2005 [Page 13]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
The DTN architecture depends on time synchronization (supported by
external, region-local protocols) for three primary purposes: bundle
identification, routing with scheduled or predicted contacts, and
bundle expiration time computations. These 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 source
timestamp on an arriving bundle is made available to consuming
applications by an API (specified elsewhere).
Each bundle is required to contain a time stamp unique to the bundle
sender's endpoint ID. The concatenation of the Source Endpoint ID
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.
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.
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." [RJ90]
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. 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.
DTN flow control decisions must be made within the bundling layer
itself based on information about resources (in this case, primarily
persistent storage) available within the bundle node. However, the
bundle layer *might* be able to delegate the implementation of those
decisions to the underlying transport protocols.
Cerf, et al. Expires January 2005 [Page 14]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
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 to demonstrate that a (DTN) 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
flood the network with traffic easily, possibly denying service to
authorized users. Implicit in this statement is a requirement for
some form of admission control and/or in-network authentication
sensitive to the requested class of service.
Many existing authorization and access control protocols designed for
operation in low-delay, connected environments may not perform well
in DTNs. In particular, the following common operations are
potentially much more difficult: updating remote access control lists
and revoking ("blacklisting") credentials. 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, each bundle includes an
immutable signature containing a verifiable identity of the sender
and other conventional cryptographic material to verify accuracy of
the message content. DTN nodes 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
considerably harder to mount as compared with conventional Internet
routers. However, the obvious cost is potentially larger computation
and storage overhead required at DTN nodes.
Our basis for authorization and authentication uses asymmetric
cryptography as a starting point for keying, and requires one or more
trusted credential-issuing authorities. Each node is issued initial
configuration information usable to assess the validity of
credentials it will be presented with in the future (e.g. a
certificate authority's public key).
An application presents verifiable public information (e.g. a signed
public key) along with a message to be carried and class of service
requested, signed with corresponding private information (e.g.
matching private key). If required by local policy, one or more DTN
nodes verify the sender's identity, and perform access control checks
against the requested class of service. Valid messages accepted for
the specified class of service are then forwarded.
Cerf, et al. Expires January 2005 [Page 15]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
In [DSEC], only first-hop routers need to cache per-user information,
and then only for adjacent users. Non-edge "core" routers can rely
on the authentication of upstream routers to verify the authenticity
of messages. This approach may 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
routers 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 DTN routers 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.
This approach is partially susceptible to compromised routers. If an
otherwise-legitimate router is compromised, it would be able to
utilize network resources at an arbitrary class of service setting
and send traffic purportedly originating from any user whose identity
is known to the router. However, if the message signature is 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.
Note that the end-to-end signatures suggested above may be checked at
selected nodes in a DTN that wish to favor stricter security over
scalability. In any case, local policy dictates the credentials a
DTN router is required to check.
4 State Management Considerations
An important aspect of any networking architecture is its management
of state information. This section describes the state information
managed at the bundle layer and discusses how it is established and
removed.
4.1 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. messages arrive). These registrations
create state information called registration state.
Registration state 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 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
Cerf, et al. Expires January 2005 [Page 16]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
hosting system's uptime). In cases where applications are not
automatically restarted but 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.).
As part of registration state, an endpoint ID for which an
application wishes to receive messages must be specified. This
operation is somewhat analogous to the bind() operation in the common
sockets API.
4.2 Custody Transfer State
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 requiring
enhanced reliability. Retransmission state and accounting state are
released upon receipt of one or more acknowledgements, 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 acknowledgment.
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.
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 infrastructure protection model described in this architecture
requires maintenance of state in all DTN nodes. All nodes are
required to store their own private information (including their own
Cerf, et al. Expires January 2005 [Page 17]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
policy and authentication material) and a block of information used
to verify credentials. Further, in most cases, DTN nodes will cache
the public information (and possibly the credentials) of their next-
hop (bundle) neighbors. All cached information will have 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).
In addition to basic authentication of applications and routers,
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.
Some DTNs may implement security boundaries enforced by selected
nodes in the network, where application credentials may be checked in
addition to checking router credentials. Public information used to
verify application authentication will typically be cached at these
points.
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 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 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 services provided by the DTN architecture are based on
asynchronous, message-oriented communication which differs from
conversational 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] or
"transaction", although transactions carry connotations of multi-
phase commitment that we do not intend here.) The goal is to
minimize synchronous interchange between applications that are
separated by a network presenting 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
Cerf, et al. Expires January 2005 [Page 18]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
file "put" operation can take as many as eight round trips to get to
a point where file data can flow [DFS02].
Delay-tolerant applications must consider additional factors beyond
the conversational implications of long delay paths. For example, an
application may terminate (voluntarily or not) between the time it
sends a message and the time it expects a response. If this
possibility has been anticipated, the application can be "re-
instantiated" with state information saved in persistent storage.
This is an implementation issue, but also an application design
consideration.
Some consideration of delay-tolerant application design can result in
applications that work reasonably well in low-delay environments, and
that do not suffer extraordinarily in high or highly-variable delay
environments.
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 routers. 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. 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, whereas a convergence layer
for some network where no reliable transport protocol exists would be
considerably more complex (e.g. it might have to implement
reliability, fragmentation, flow-control, etc.).
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 2005 [Page 19]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
8 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.
9 IANA Considerations
This document specifies the architecture for Delay Tolerant
Networking and does not itself require any actions from IANA.
10 Normative References
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3667, February 2004.
[RFC3668] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
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
[NEWARCH] NewArch Project: Future-Generation Internet Architecture.
http://www.isi.edu/newarch
[IPNL] P. Francis, R. Gummadi, "IPNL: A NAT-Extended Internet
Architecture," Proceedings SIGCOMM, 2001.
[TRIAD] D. Cheriton, M. Gritter, "TRIAD: A new next generation
internet architecture," 2001. Available from
http://www-dsg.stanford.edu/triad/triad.ps.gz
Cerf, et al. Expires January 2005 [Page 20]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
[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.
[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.
[RJ90] R. Jain, "Congestion Control in Computer Networks: Issues and
Trends," IEEE Network Magazine, May 1990.
[DSEC] R. Durst, "Infrastructure Security Model for Delay Tolerant
Networks," White paper in progress, July 2002. Available from
http://www.dtnrg.org/papers/dtn-sec-wp-v5.pdf
[CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a
new generation of protocols," Proceedings SIGCOMM, 1990.
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
7515 Colshire Blvd.
M/S H300
McLean, VA 22102
Telephone +1 (703) 883-7535
FAX +1 (703) 883-7142
Email durst@mitre.org
Cerf, et al. Expires January 2005 [Page 21]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
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
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.
Cerf, et al. Expires January 2005 [Page 22]
Internet Draft draft-irtf-dtnrg-arch-02.txt July 2004
Copyright Notice
Copyright (C) The Internet Society (2004). 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
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
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.
Release Statement
By submitting this Internet-Draft, the authors accept the provisions
of Section 4 of RFC 3667.
Cerf, et al. Expires January 2005 [Page 23] | PAFTECH AB 2003-2026 | 2026-04-23 11:34:47 |