GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4838

Network Working Group V. Cerf Request for Comments: 4838 Google/Jet Propulsion Laboratory Category: Informational S. Burleigh

                                                              A. Hooke
                                                          L. Torgerson
                                        NASA/Jet Propulsion Laboratory
                                                              R. Durst
                                                              K. Scott
                                                 The MITRE Corporation
                                                               K. Fall
                                                     Intel Corporation
                                                              H. Weiss
                                                          SPARTA, Inc.
                                                            April 2007
              Delay-Tolerant Networking Architecture

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

IESG Note

 This RFC is a product of the Internet Research Task Force and is not
 a candidate for any level of Internet Standard.  The IRTF publishes
 the results of Internet-related research and development activities.
 These results might not be suitable for deployment on the public
 Internet.

Abstract

 This document describes an architecture for delay-tolerant and
 disruption-tolerant networks, and is an evolution of the architecture
 originally designed for the Interplanetary Internet, a communication
 system envisioned to provide Internet-like services across
 interplanetary distances in support of deep space exploration.  This
 document describes an architecture that addresses a variety of
 problems with internetworks having operational and performance
 characteristics that make conventional (Internet-like) networking
 approaches either unworkable or impractical.  We define a message-
 oriented overlay that exists above the transport (or other) layers of

Cerf, et al. Informational [Page 1] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 the networks it interconnects.  The document presents a motivation
 for the architecture, an architectural overview, review of state
 management required for its operation, and a discussion of
 application design issues.  This document represents the consensus of
 the IRTF DTN research group and has been widely reviewed by that
 group.

Table of Contents

 1. Introduction ....................................................3
 2. Why an Architecture for Delay-Tolerant Networking? ..............4
 3. DTN Architectural Description ...................................5
    3.1. Virtual Message Switching Using Store-and-Forward
         Operation ..................................................5
    3.2. Nodes and Endpoints ........................................7
    3.3. Endpoint Identifiers (EIDs) and Registrations ..............8
    3.4. Anycast and Multicast .....................................10
    3.5. Priority Classes ..........................................10
    3.6. Postal-Style Delivery Options and Administrative Records ..11
    3.7. Primary Bundle Fields .....................................15
    3.8. Routing and Forwarding ....................................16
    3.9. Fragmentation and Reassembly ..............................18
    3.10. Reliability and Custody Transfer .........................19
    3.11. DTN Support for Proxies and Application Layer Gateways ...21
    3.12. Timestamps and Time Synchronization ......................22
    3.13. Congestion and Flow Control at the Bundle Layer ..........22
    3.14. Security .................................................23
 4. State Management Considerations ................................25
    4.1. Application Registration State ............................25
    4.2. Custody Transfer State ....................................26
    4.3. Bundle Routing and Forwarding State .......................26
    4.4. Security-Related State ....................................27
    4.5. Policy and Configuration State ............................27
 5. Application Structuring Issues .................................28
 6. Convergence Layer Considerations for Use of Underlying
    Protocols ......................................................28
 7. Summary ........................................................29
 8. Security Considerations ........................................29
 9. IANA Considerations ............................................30
 10. Normative References ..........................................30
 11. Informative References ........................................30
 12. Acknowledgments ...............................................32

Cerf, et al. Informational [Page 2] RFC 4838 Delay-Tolerant Networking Architecture April 2007

1. Introduction

 This document describes an architecture for delay and disruption-
 tolerant interoperable networking (DTN).  The architecture embraces
 the concepts of occasionally-connected networks that may suffer from
 frequent partitions and that may be comprised of more than one
 divergent set of protocols or protocol families.  The basis for this
 architecture lies with that of the Interplanetary Internet, which
 focused primarily on the issue of deep space communication in high-
 delay environments.  We expect the DTN architecture described here to
 be utilized in various operational environments, including those
 subject to disruption and disconnection and those with high-delay;
 the case of deep space is one specialized example of these, and is
 being pursued as a specialization of this architecture (See [IPN01]
 and [SB03] for more details).
 Other networks to which we believe this architecture applies include
 sensor-based networks using scheduled intermittent connectivity,
 terrestrial wireless networks that cannot ordinarily maintain end-to-
 end connectivity, satellite networks with moderate delays and
 periodic connectivity, and underwater acoustic networks with moderate
 delays and frequent interruptions due to environmental factors.  A
 DTN tutorial [FW03], aimed at introducing DTN and the types of
 networks for which it is designed, is available to introduce new
 readers to the fundamental concepts and motivation.  More technical
 descriptions may be found in [KF03], [JFP04], [JDPF05], and [WJMF05].
 We define an end-to-end message-oriented overlay called the "bundle
 layer" that exists at a layer above the transport (or other) layers
 of the networks on which it is hosted and below applications.
 Devices implementing the bundle layer are called DTN nodes.  The
 bundle layer forms an overlay that employs persistent storage to help
 combat network interruption.  It includes a hop-by-hop transfer of
 reliable delivery responsibility and optional end-to-end
 acknowledgement.  It also includes a number of diagnostic and
 management features.  For interoperability, it uses a flexible naming
 scheme (based on Uniform Resource Identifiers [RFC3986]) capable of
 encapsulating different naming and addressing schemes in the same
 overall naming syntax.  It also has a basic security model,
 optionally enabled, aimed at protecting infrastructure from
 unauthorized use.
 The bundle layer provides functionality similar to the internet layer
 of gateways described in the original ARPANET/Internet designs
 [CK74].  It differs from ARPANET gateways, however, because it is
 layer-agnostic and is focused on virtual message forwarding rather
 than packet switching.  However, both generally provide
 interoperability between underlying protocols specific to one

Cerf, et al. Informational [Page 3] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 environment and those protocols specific to another, and both provide
 a store-and-forward forwarding service (with the bundle layer
 employing persistent storage for its store and forward function).
 In a sense, the DTN architecture provides a common method for
 interconnecting heterogeneous gateways or proxies that employ store-
 and-forward message routing to overcome communication disruptions.
 It provides services similar to electronic mail, but with enhanced
 naming, routing, and security capabilities.  Nodes unable to support
 the full capabilities required by this architecture may be supported
 by application-layer proxies acting as DTN applications.

2. Why an Architecture for Delay-Tolerant Networking?

 Our motivation for pursuing an architecture for delay tolerant
 networking stems from several factors.  These factors are summarized
 below; much more detail on their rationale can be explored in [SB03],
 [KF03], and [DFS02].
 The existing Internet protocols do not work well for some
 environments, due to some fundamental assumptions built into the
 Internet architecture:
  1. that an end-to-end path between source and destination exists for

the duration of a communication session

  1. (for reliable communication) that retransmissions based on timely

and stable feedback from data receivers is an effective means for

   repairing errors
  1. that end-to-end loss is relatively small
  1. that all routers and end stations support the TCP/IP protocols
  1. that applications need not worry about communication performance
  1. that endpoint-based security mechanisms are sufficient for meeting

most security concerns

  1. that packet switching is the most appropriate abstraction for

interoperability and performance

  1. that selecting a single route between sender and receiver is

sufficient for achieving acceptable communication performance

 The DTN architecture is conceived to relax most of these assumptions,
 based on a number of design principles that are summarized here (and
 further discussed in [KF03]):

Cerf, et al. Informational [Page 4] RFC 4838 Delay-Tolerant Networking Architecture April 2007

  1. Use variable-length (possibly long) messages (not streams or

limited-sized packets) as the communication abstraction to help

   enhance the ability of the network to make good scheduling/path
   selection decisions when possible.
  1. Use a naming syntax that supports a wide range of naming and

addressing conventions to enhance interoperability.

  1. Use storage within the network to support store-and-forward

operation over multiple paths, and over potentially long timescales

   (i.e., to support operation in environments where many and/or no
   end-to-end paths may ever exist); do not require end-to-end
   reliability.
  1. Provide security mechanisms that protect the infrastructure from

unauthorized use by discarding traffic as quickly as possible.

  1. Provide coarse-grained classes of service, delivery options, and a

way to express the useful lifetime of data to allow the network to

   better deliver data in serving the needs of applications.
 The use of the bundle layer is guided not only by its own design
 principles, but also by a few application design principles:
  1. Applications should minimize the number of round-trip exchanges.
  1. Applications should cope with restarts after failure while network

transactions remain pending.

  1. Applications should inform the network of the useful life and

relative importance of data to be delivered.

 These issues are discussed in further detail in Section 5.

3. DTN Architectural Description

 The previous section summarized the design principles that guide the
 definition of the DTN architecture.  This section presents a
 description of the major features of the architecture resulting from
 design decisions guided by the aforementioned design principles.

3.1. Virtual Message Switching Using Store-and-Forward Operation

 A DTN-enabled application sends messages of arbitrary length, also
 called Application Data Units or ADUs [CT90], which are subject to
 any implementation limitations.  The relative order of ADUs might not
 be preserved.  ADUs are typically sent by and delivered to

Cerf, et al. Informational [Page 5] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 applications in complete units, although a system interface that
 behaves differently is not precluded.
 ADUs are transformed by the bundle layer into one or more protocol
 data units called "bundles", which are forwarded by DTN nodes.
 Bundles have a defined format containing two or more "blocks" of
 data.  Each block may contain either application data or other
 information used to deliver the containing bundle to its
 destination(s).  Blocks serve the purpose of holding information
 typically found in the header or payload portion of protocol data
 units in other protocol architectures.  The term "block" is used
 instead of "header" because blocks may not appear at the beginning of
 a bundle due to particular processing requirements (e.g., digital
 signatures).
 Bundles may be split up ("fragmented") into multiple constituent
 bundles (also called "fragments" or "bundle fragments") during
 transmission.  Fragments are themselves bundles, and may be further
 fragmented.  Two or more fragments may be reassembled anywhere in the
 network, forming a new bundle.
 Bundle sources and destinations are identified by (variable-length)
 Endpoint Identifiers (EIDs, described below), which identify the
 original sender and final destination(s) of bundles, respectively.
 Bundles also contain a "report-to" EID used when special operations
 are requested to direct diagnostic output to an arbitrary entity
 (e.g., other than the source).  An EID may refer to one or more DTN
 nodes (i.e., for multicast destinations or "report-to" destinations).
 While IP networks are based on "store-and-forward" operation, there
 is an assumption that the "storing" will not persist for more than a
 modest amount of time, on the order of the queuing and transmission
 delay.  In contrast, the DTN architecture does not expect that
 network links are always available or reliable, and instead expects
 that nodes may choose to store bundles 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 bundles will survive
 system restarts.
 Bundles contain an originating timestamp, useful life indicator, a
 class of service designator, and a length.  This information provides
 bundle-layer routing with a priori knowledge of the size and
 performance requirements of requested data transfers.  When there is
 a significant amount of queuing that can occur in the network (as is
 the case in the DTN version of store-and-forward), the advantage
 provided by knowing this information may be significant for making
 scheduling and path selection decisions [JFP04].  An alternative
 abstraction (i.e., of stream-based delivery based on packets) would

Cerf, et al. Informational [Page 6] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 make such scheduling much more difficult.  Although packets provide
 some of the same benefits as bundles, larger aggregates provide a way
 for the network to apply scheduling and buffer management to units of
 data that are more useful to applications.
 An essential element of the bundle-based style of forwarding is that
 bundles have a place to wait in a queue until a communication
 opportunity ("contact") is available.  This highlights the following
 assumptions:
 1. that storage is available and well-distributed throughout the
    network,
 2. that storage is sufficiently persistent and robust to store
    bundles until forwarding can occur, and
 3. (implicitly) that this "store-and-forward" model is a better
    choice than attempting to effect continuous connectivity or other
    alternatives.
 For a network to effectively support the DTN architecture, these
 assumptions must be considered and must be found to hold.  Even so,
 the inclusion of long-term storage as a fundamental aspect of the DTN
 architecture poses new problems, especially with respect to
 congestion management and denial-of-service mitigation.  Node storage
 in essence represents a new resource that must be managed and
 protected.  Much of the research in DTN revolves around exploring
 these issues.  Congestion is discussed in Section 3.13, and security
 mechanisms, including methods for DTN nodes to protect themselves
 from handling unauthorized traffic from other nodes, are discussed in
 [DTNSEC] and [DTNSOV].

3.2. Nodes and Endpoints

 A DTN node (or simply "node" in this document) is an engine for
 sending and receiving bundles -- an implementation of the bundle
 layer.  Applications utilize DTN nodes to send or receive ADUs
 carried in bundles (applications also use DTN nodes when acting as
 report-to destinations for diagnostic information carried in
 bundles).  Nodes may be members of groups called "DTN endpoints".  A
 DTN endpoint is therefore a set of DTN nodes.  A bundle is considered
 to have been successfully delivered to a DTN endpoint when some
 minimum subset of the nodes in the endpoint has received the bundle
 without error.  This subset is called the "minimum reception group"
 (MRG) of the endpoint.  The MRG of an endpoint may refer to one node
 (unicast), one of a group of nodes (anycast), or all of a group of
 nodes (multicast and broadcast).  A single node may be in the MRG of
 multiple endpoints.

Cerf, et al. Informational [Page 7] RFC 4838 Delay-Tolerant Networking Architecture April 2007

3.3. Endpoint Identifiers (EIDs) and Registrations

 An Endpoint Identifier (EID) is a name, expressed using the general
 syntax of URIs (see below), that identifies a DTN endpoint.  Using an
 EID, a node is able to determine the MRG of the DTN endpoint named by
 the EID.  Each node is also required to have at least one EID that
 uniquely identifies it.
 Applications send ADUs destined for an EID, and may arrange for ADUs
 sent to a particular EID to be delivered to them.  Depending on the
 construction of the EID being used (see below), there may be a
 provision for wildcarding some portion of an EID, which is often
 useful for diagnostic and routing purposes.
 An application's desire to receive ADUs destined for a particular EID
 is called a "registration", and in general is maintained persistently
 by a DTN node.  This allows application registration information to
 survive application and operating system restarts.
 An application's attempt to establish a registration is not
 guaranteed to succeed.  For example, an application could request to
 register itself to receive ADUs by specifying an Endpoint ID that is
 uninterpretable or unavailable to the DTN node servicing the request.
 Such requests are likely to fail.

3.3.1. URI Schemes

 Each Endpoint ID is expressed syntactically as a Uniform Resource
 Identifier (URI) [RFC3986].  The URI syntax has been designed as a
 way to express names or addresses for a wide range of purposes, and
 is therefore useful for constructing names for DTN endpoints.
 In URI terminology, each URI begins with a scheme name.  The scheme
 name is an element of the set of globally-managed scheme names
 maintained by IANA [ISCHEMES].  Lexically following the scheme name
 in a URI is a series of characters constrained by the syntax defined
 by the scheme.  This portion of the URI is called the scheme-specific
 part (SSP), and can be quite general.  (See, as one example, the URI
 scheme for SNMP [RFC4088]).  Note that scheme-specific syntactical
 and semantic restrictions may be more constraining than the basic
 rules of RFC 3986.  Section 3.1 of RFC 3986 provides guidance on the
 syntax of scheme names.
 URI schemes are a key concept in the DTN architecture, and evolved
 from an earlier concept called regions, which were tied more closely
 to assumptions of the network topology.  Using URIs, significant
 flexibility is attained in the structuring of EIDs.  They might, for
 example, be constructed based on DNS names, or might look like

Cerf, et al. Informational [Page 8] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 "expressions of interest" or forms of database-like queries as in a
 directed diffusion-routed network [IGE00] or in intentional naming
 [WSBL99].  As names, EIDs are not required to be related to routing
 or topological organization.  Such a relationship is not prohibited,
 however, and in some environments using EIDs this way may be
 advantageous.
 A single EID may refer to an endpoint containing more than one DTN
 node, as suggested above.  It is the responsibility of a scheme
 designer to define how to interpret the SSP of an EID so as to
 determine whether it refers to a unicast, multicast, or anycast set
 of nodes.  See Section 3.4 for more details.
 URIs are constructed based on rules specified in RFC 3986, using the
 US-ASCII character set.  However, note this excerpt from RFC 3986,
 Section 1.2.1, on dealing with characters that cannot be represented
 by US-ASCII:  "Percent-encoded octets (Section 2.1) may be used
 within a URI to represent characters outside the range of the US-
 ASCII coded character set if this representation is allowed by the
 scheme or by the protocol element in which the URI is referenced.
 Such a definition should specify the character encoding used to map
 those characters to octets prior to being percent-encoded for the
 URI".

3.3.2. Late Binding

 Binding means interpreting the SSP of an EID for the purpose of
 carrying an associated message towards a destination.  For example,
 binding might require mapping an EID to a next-hop EID or to a lower-
 layer address for transmission.  "Late binding" means that the
 binding of a bundle's destination to a particular set of destination
 identifiers or addresses does not necessarily happen at the bundle
 source.  Because the destination EID is potentially re-interpreted at
 each hop, the binding may occur at the source, during transit, or
 possibly at the destination(s).  This contrasts with the name-to-
 address binding of Internet communications where a DNS lookup at the
 source fixes the IP address of the destination node before data is
 sent.  Such a circumstance would be considered "early binding"
 because the name-to-address translation is performed prior to data
 being sent into the network.
 In a frequently-disconnected network, late binding may be
 advantageous because the transit time of a message may exceed the
 validity time of a binding, making binding at the source impossible
 or invalid.  Furthermore, use of name-based routing with late binding
 may reduce the amount of administrative (mapping) information that

Cerf, et al. Informational [Page 9] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 must propagate through the network, and may also limit the scope of
 mapping synchronization requirements to a local topological
 neighborhood where changes are made.

3.4. Anycast and Multicast

 As mentioned above, an EID may refer to an endpoint containing one or
 more DTN nodes.  When referring to a group of size greater than one,
 the delivery semantics may be of either the anycast or multicast
 variety (broadcast is considered to be of the multicast variety).
 For anycast group delivery, a bundle is delivered to one node among a
 group of potentially many nodes, and for multicast delivery it is
 intended to be delivered to all of them, subject to the normal DTN
 class of service and maximum useful lifetime semantics.
 Multicast group delivery in a DTN presents an unfamiliar issue with
 respect to group membership.  In relatively low-delay networks, such
 as the Internet, nodes may be considered to be part of the group if
 they have expressed interest to join it "recently".  In a DTN,
 however, nodes may wish to receive data sent to a group during an
 interval of time earlier than when they are actually able to receive
 it [ZAZ05].  More precisely, an application expresses its desire to
 receive data sent to EID e at time t.  Prior to this, during the
 interval [t0, t1], t > t1, data may have been generated for group e.
 For the application to receive any of this data, the data must be
 available a potentially long time after senders have ceased sending
 to the group.  Thus, the data may need to be stored within the
 network in order to support temporal group semantics of this kind.
 How to design and implement this remains a research issue, as it is
 likely to be at least as hard as problems related to reliable
 multicast.

3.5. Priority Classes

 The DTN architecture offers *relative* measures of priority (low,
 medium, high) for delivering ADUs.  These priorities differentiate
 traffic based upon an application's desire to affect the delivery
 urgency for ADUs, and are carried in bundle blocks generated by the
 bundle layer based on information specified by the application.
 The (U.S. or similar) Postal Service provides a strong metaphor for
 the priority classes offered by the forwarding abstraction offered by
 the DTN architecture.  Traffic is generally not interactive and is
 often one-way.  There are generally no strong guarantees of timely
 delivery, yet there are some forms of class of service, reliability,
 and security.

Cerf, et al. Informational [Page 10] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 We have defined three relative priority classes to date.  These
 priority classes typically imply some relative scheduling
 prioritization among bundles in queue at a sender:
  1. Bulk - Bulk bundles are shipped on a "least effort" basis. No

bundles of this class will be shipped until all bundles of other

   classes bound for the same destination and originating from the
   same source have been shipped.
  1. Normal - Normal-class bundles are shipped prior to any bulk-class

bundles and are otherwise the same as bulk bundles.

  1. Expedited - Expedited bundles, in general, are shipped prior to

bundles of other classes and are otherwise the same.

 Applications specify their requested priority class and data lifetime
 (see below) for each ADU they send.  This information, coupled with
 policy applied at DTN nodes that select how messages are forwarded
 and which routing algorithms are in use, affects the overall
 likelihood and timeliness of ADU delivery.
 The priority class of a bundle is only required to relate to other
 bundles from the same source.  This means that a high priority bundle
 from one source may not be delivered faster (or with some other
 superior quality of service) than a medium priority bundle from a
 different source.  It does mean that a high priority bundle from one
 source will be handled preferentially to a lower priority bundle sent
 from the same source.
 Depending on a particular DTN node's forwarding/scheduling policy,
 priority may or may not be enforced across different sources.  That
 is, in some DTN nodes, expedited bundles might always be sent prior
 to any bulk bundles, irrespective of source.  Many variations are
 possible.

3.6. Postal-Style Delivery Options and Administrative Records

 Continuing with the postal analogy, the DTN architecture supports
 several delivery options that may be selected by an application when
 it requests the transmission of an ADU.  In addition, the
 architecture defines two types of administrative records: "status
 reports" and "signals".  These records are bundles that provide
 information about the delivery of other bundles, and are used in
 conjunction with the delivery options.

Cerf, et al. Informational [Page 11] RFC 4838 Delay-Tolerant Networking Architecture April 2007

3.6.1. Delivery Options

 We have defined eight delivery options.  Applications sending an ADU
 (the "subject ADU") may request any combination of the following,
 which are carried in each of the bundles produced ("sent bundles") by
 the bundle layer resulting from the application's request to send the
 subject ADU:
  1. Custody Transfer Requested - requests sent bundles be delivered

with enhanced reliability using custody transfer procedures. Sent

   bundles will be transmitted by the bundle layer using reliable
   transfer protocols (if available), and the responsibility for
   reliable delivery of the bundle to its destination(s) may move
   among one or more "custodians" in the network.  This capability is
   described in more detail in Section 3.10.
  1. Source Node Custody Acceptance Required - requires the source DTN

node to provide custody transfer for the sent bundles. If custody

   transfer is not available at the source when this delivery option
   is requested, the requested transmission fails.  This provides a
   means for applications to insist that the source DTN node take
   custody of the sent bundles (e.g., by storing them in persistent
   storage).
  1. Report When Bundle Delivered - requests a (single) Bundle Delivery

Status Report be generated when the subject ADU is delivered to its

   intended recipient(s).  This request is also known as "return-
   receipt".
  1. Report When Bundle Acknowledged by Application - requests an

Acknowledgement Status Report be generated when the subject ADU is

   acknowledged by a receiving application.  This only happens by
   action of the receiving application, and differs from the Bundle
   Delivery Status Report.  It is intended for cases where the
   application may be acting as a form of application layer gateway
   and wishes to indicate the status of a protocol operation external
   to DTN back to the requesting source.  See Section 11 for more
   details.
  1. Report When Bundle Received - requests a Bundle Reception Status

Report be generated when each sent bundle arrives at a DTN node.

   This is designed primarily for diagnostic purposes.
  1. Report When Bundle Custody Accepted - requests a Custody

Acceptance Status Report be generated when each sent bundle has

   been accepted using custody transfer.  This is designed primarily
   for diagnostic purposes.

Cerf, et al. Informational [Page 12] RFC 4838 Delay-Tolerant Networking Architecture April 2007

  1. Report When Bundle Forwarded - requests a Bundle Forwarding Status

Report be generated when each sent bundle departs a DTN node after

   forwarding.  This is designed primarily for diagnostic purposes.
  1. Report When Bundle Deleted - requests a Bundle Deletion Status

Report be generated when each sent bundle is deleted at a DTN node.

   This is designed primarily for diagnostic purposes.
 The first four delivery options are designed for ordinary use by
 applications.  The last four are designed primarily for diagnostic
 purposes and their use may be restricted or limited in environments
 subject to congestion or attack.
 If the security procedures defined in [DTNSEC] are also enabled, then
 three additional delivery options become available:
  1. Confidentiality Required - requires the subject ADU be made secret

from parties other than the source and the members of the

   destination EID.
  1. Authentication Required - requires all non-mutable fields in the

bundle blocks of the sent bundles (i.e., those which do not change

   as the bundle is forwarded) be made strongly verifiable (i.e.,
   cryptographically strong).  This protects several fields, including
   the source and destination EIDs and the bundle's data.  See Section
   3.7 and [BSPEC] for more details.
  1. Error Detection Required - requires modifications to the non-

mutable fields of each sent bundle be made detectable with high

   probability at each destination.

3.6.2. Administrative Records: Bundle Status Reports and Custody

      Signals
 Administrative records are used to report status information or error
 conditions related to the bundle layer.  There are two types of
 administrative records defined:  bundle status reports (BSRs) and
 custody signals.  Administrative records correspond (approximately)
 to messages in the ICMP protocol in IP [RFC792].  In ICMP, however,
 messages are returned to the source.  In DTN, they are instead
 directed to the report-to EID for BSRs and the EID of the current
 custodian for custody signals, which might differ from the source's
 EID.  Administrative records are sent as bundles with a source EID
 set to one of the EIDs associated with the DTN node generating the
 administrative record.  In some cases, arrival of a single bundle or
 bundle fragment may elicit multiple administrative records (e.g., in
 the case where a bundle is replicated for multicast forwarding).

Cerf, et al. Informational [Page 13] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 The following BSRs are currently defined (also see [BSPEC] for more
 details):
  1. Bundle Reception - sent when a bundle arrives at a DTN node.

Generation of this message may be limited by local policy.

  1. Custody Acceptance - sent when a node has accepted custody of a

bundle with the Custody Transfer Requested option set. Generation

   of this message may be limited by local policy.
  1. Bundle Forwarded - sent when a bundle containing a Report When

Bundle Forwarded option departs from a DTN node after having been

   forwarded.  Generation of this message may be limited by local
   policy.
  1. Bundle Deletion - sent from a DTN node when a bundle containing a

Report When Bundle Deleted option is discarded. This can happen

   for several reasons, such as expiration.  Generation of this
   message may be limited by local policy but is required in cases
   where the deletion is performed by a bundle's current custodian.
  1. Bundle Delivery - sent from a final recipient's (destination) node

when a complete ADU comprising sent bundles containing Report When

   Bundle Delivered options is consumed by an application.
  1. Acknowledged by application - sent from a final recipient's

(destination) node when a complete ADU comprising sent bundles

   containing Application Acknowledgment options has been processed by
   an application.  This generally involves specific action on the
   receiving application's part.
 In addition to the status reports, the custody signal is currently
 defined to indicate the status of a custody transfer.  These are sent
 to the current-custodian EID contained in an arriving bundle:
  1. Custody Signal - indicates that custody has been successfully

transferred. This signal appears as a Boolean indicator, and may

   therefore indicate either a successful or a failed custody transfer
   attempt.
 Administrative records must reference a received bundle.  This is
 accomplished by a method for uniquely identifying bundles based on a
 transmission timestamp and sequence number discussed in Section 3.12.

Cerf, et al. Informational [Page 14] RFC 4838 Delay-Tolerant Networking Architecture April 2007

3.7. Primary Bundle Fields

 The bundles carried between and among DTN nodes obey a standard
 bundle protocol specified in [BSPEC].  Here we provide an overview of
 most of the fields carried with every bundle.  The protocol is
 designed with a mandatory primary block, an optional payload block
 (which contains the ADU data itself), and a set of optional extension
 blocks.  Blocks may be cascaded in a way similar to extension headers
 in IPv6.  The following selected fields are all present in the
 primary block, and therefore are present for every bundle and
 fragment:
  1. Creation Timestamp - a concatenation of the bundle's creation time

and a monotonically increasing sequence number such that the

   creation timestamp is guaranteed to be unique for each ADU
   originating from the same source.  The creation timestamp is based
   on the time-of-day an application requested an ADU to be sent (not
   when the corresponding bundle(s) are sent into the network).  DTN
   nodes are assumed to have a basic time synchronization capability
   (see Section 3.12).
  1. Lifespan - the time-of-day at which the message is no longer

useful. If a bundle is stored in the network (including the

   source's DTN node) when its lifespan is reached, it may be
   discarded.  The lifespan of a bundle is expressed as an offset
   relative to its creation time.
  1. Class of Service Flags - indicates the delivery options and

priority class for the bundle. Priority classes may be one of

   bulk, normal, or expedited.  See Section 3.6.1.
  1. Source EID - EID of the source (the first sender).
  1. Destination EID - EID of the destination (the final intended

recipient(s)).

  1. Report-To Endpoint ID - an EID identifying where reports (return-

receipt, route-tracing functions) should be sent. This may or may

   not identify the same endpoint as the Source EID.
  1. Custodian EID - EID of the current custodian of a bundle (if any).
 The payload block indicates information about the contained payload
 (e.g., its length) and the payload itself.  In addition to the fields
 found in the primary and payload blocks, each bundle may have fields
 in additional blocks carried with each bundle.  See [BSPEC] for
 additional details.

Cerf, et al. Informational [Page 15] RFC 4838 Delay-Tolerant Networking Architecture April 2007

3.8. Routing and Forwarding

 The DTN architecture provides a framework for routing and forwarding
 at the bundle layer for unicast, anycast, and multicast messages.
 Because nodes in a DTN network might be interconnected using more
 than one type of underlying network technology, a DTN network is best
 described abstractly using a *multigraph* (a graph where vertices may
 be interconnected with more than one edge).  Edges in this graph are,
 in general, time-varying with respect to their delay and capacity and
 directional because of the possibility of one-way connectivity.  When
 an edge has zero capacity, it is considered to not be connected.
 Because edges in a DTN graph may have significant delay, it is
 important to distinguish where time is measured when expressing an
 edge's capacity or delay.  We adopt the convention of expressing
 capacity and delay as functions of time where time is measured at the
 point where data is inserted into a network edge.  For example,
 consider an edge having capacity C(t) and delay D(t) at time t.  If B
 bits are placed in this edge at time t, they completely arrive by
 time t + D(t) + (1/C(t))*B.  We assume C(t) and D(t) do not change
 significantly during the interval [t, t+D(t)+(1/C(t))*B].
 Because edges may vary between positive and zero capacity, it is
 possible to describe a period of time (interval) during which the
 capacity is strictly positive, and the delay and capacity can be
 considered to be constant [AF03].  This period of time is called a
 "contact".  In addition, the product of the capacity and the interval
 is known as a contact's "volume".  If contacts and their volumes are
 known ahead of time, intelligent routing and forwarding decisions can
 be made (optimally for small networks) [JFP04].  Optimally using a
 contact's volume, however, requires the ability to divide large ADUs
 and bundles into smaller routable units.  This is provided by DTN
 fragmentation (see Section 3.9).
 When delivery paths through a DTN graph are lossy or contact
 intervals and volumes are not known precisely ahead of time, routing
 computations become especially challenging.  How to handle these
 situations is an active area of work in the (emerging) research area
 of delay tolerant networking.

3.8.1. Types of Contacts

 Contacts typically fall into one of several categories, based largely
 on the predictability of their performance characteristics and
 whether some action is required to bring them into existence.  To
 date, the following major types of contacts have been defined:

Cerf, et al. Informational [Page 16] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 Persistent Contacts
    Persistent contacts are always available (i.e., no connection-
    initiation action is required to instantiate a persistent
    contact).  An 'always-on' Internet connection such as a DSL or
    Cable Modem connection would be a representative of this class.
 On-Demand Contacts
    On-Demand contacts require some action in order to 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 contact at a
    particular time, for a particular duration.  An example of a
    scheduled contact is a link with a low-earth orbiting satellite.
    A node's list of contacts with the satellite can be constructed
    from the satellite's schedule of view times, capacities, and
    latencies.  Note that for networks with substantial delays, the
    notion of the "particular time" is delay-dependent.  For example,
    a single scheduled contact between Earth and Mars would not be at
    the same instant in each location, but would instead be offset by
    the (non-negligible) propagation delay.
 Intermittent - Opportunistic Contacts
    Opportunistic contacts are not scheduled, but rather present
    themselves unexpectedly.  For example, an unscheduled aircraft
    flying overhead and beaconing, advertising its availability for
    communication, would present an opportunistic contact.  Another
    type of opportunistic contact might be via an infrared or
    Bluetooth communication link between a personal digital assistant
    (PDA) and a kiosk in an airport concourse.  The opportunistic
    contact begins as the PDA is brought near the kiosk, lasting an
    undetermined amount of time (i.e., until the link is lost or
    terminated).
 Intermittent - Predicted Contacts
    Predicted contacts are based on no fixed schedule, but rather are
    predictions of likely contact times and durations based on a
    history of previously observed contacts or some other information.
    Given a great enough confidence in a predicted contact, routes may

Cerf, et al. Informational [Page 17] RFC 4838 Delay-Tolerant Networking Architecture April 2007

    be chosen based on this information.  This is an active research
    area, and a few approaches having been proposed [LFC05].

3.9. Fragmentation and Reassembly

 DTN fragmentation and reassembly are designed to improve the
 efficiency of bundle transfers by ensuring that contact volumes are
 fully utilized and by avoiding retransmission of partially-forwarded
 bundles.  There are two forms of DTN fragmentation/reassembly:
 Proactive Fragmentation
    A DTN node may divide a block of application data into multiple
    smaller blocks and transmit each such block as an independent
    bundle.  In this case, the *final destination(s)* are responsible
    for extracting the smaller blocks from incoming bundles and
    reassembling them into the original larger bundle and, ultimately,
    ADU.  This approach is called proactive fragmentation because it
    is used primarily when contact volumes are known (or predicted) in
    advance.
 Reactive Fragmentation
    DTN nodes sharing an edge in the DTN graph may fragment a bundle
    cooperatively when a bundle is only partially transferred.  In
    this case, the receiving bundle layer modifies the incoming bundle
    to indicate it is a fragment, and forwards it normally.  The
    previous- hop sender may learn (via convergence-layer protocols,
    see Section 6) that only a portion of the bundle was delivered to
    the next hop, and send the remaining portion(s) when subsequent
    contacts become available (possibly to different next-hops if
    routing changes).  This is called reactive fragmentation because
    the fragmentation process occurs after an attempted transmission
    has taken place.
    As an example, consider a ground station G, and two store-and-
    forward satellites S1 and S2, in opposite low-earth orbit.  While
    G is transmitting a large bundle to S1, a reliable transport layer
    protocol below the bundle layer at each indicates the transmission
    has terminated, but that half the transfer has completed
    successfully.  In this case, G can form a smaller bundle fragment
    consisting of the second half of the original bundle and forward
    it to S2 when available.  In addition, S1 (now out of range of G)
    can form a new bundle consisting of the first half of the original
    bundle and forward it to whatever next hop(s) it deems
    appropriate.

Cerf, et al. Informational [Page 18] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 The reactive fragmentation capability is not required to be available
 in every DTN implementation, as it requires a certain level of
 support from underlying protocols that may not be present, and
 presents significant challenges with respect to handling digital
 signatures and authentication codes on messages.  When a signed
 message is only partially received, most message authentication codes
 will fail.  When DTN security is present and enabled, it may
 therefore be necessary to proactively fragment large bundles into
 smaller units that are more convenient for digital signatures.
 Even if reactive fragmentation is not present in an implementation,
 the ability to reassemble fragments at a destination is required in
 order to support DTN fragmentation.  Furthermore, for contacts with
 volumes that are small compared to typical bundle sizes, some
 incremental delivery approach must be used (e.g., checkpoint/restart)
 to prevent data delivery livelock.  Reactive fragmentation is one
 such approach, but other protocol layers could potentially handle
 this issue as well.

3.10. Reliability and Custody Transfer

 The most basic service provided by the bundle layer is
 unacknowledged, prioritized (but not guaranteed) unicast message
 delivery.  It also provides two options for enhancing delivery
 reliability:  end-to-end acknowledgments and custody transfer.
 Applications wishing to implement their own end-to-end message
 reliability mechanisms are free to utilize the acknowledgment.  The
 custody transfer feature of the DTN architecture only specifies a
 coarse-grained retransmission capability, described next.
 Transmission of bundles with the Custody Transfer Requested option
 specified generally involves moving the responsibility for reliable
 delivery of an ADU's bundles among different DTN nodes in the
 network.  For unicast delivery, this will typically involve moving
 bundles "closer" (in terms of some routing metric) to their ultimate
 destination(s), and retransmitting when necessary.  The nodes
 receiving these bundles along the way (and agreeing to accept the
 reliable delivery responsibility) are called "custodians".  The
 movement of a bundle (and its delivery responsibility) from one node
 to another is called a "custody transfer".  It is analogous to a
 database commit transaction [FHM03].  The exact meaning and design of
 custody transfer for multicast and anycast delivery remains to be
 fully explored.
 Custody transfer allows the source to delegate retransmission
 responsibility and recover its retransmission-related resources
 relatively soon after sending a bundle (on the order of the minimum
 round-trip time to the first bundle hop(s)).  Not all nodes in a DTN

Cerf, et al. Informational [Page 19] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 are required by the DTN architecture to accept custody transfers, so
 it is not a true 'hop-by-hop' mechanism.  For example, some nodes may
 have sufficient storage resources to sometimes act as custodians, but
 may elect to not offer such services when congested or running low on
 power.
 The existence of custodians can alter the way DTN routing is
 performed.  In some circumstances, it may be beneficial to move a
 bundle to a custodian as quickly as possible even if the custodian is
 further away (in terms of distance, time or some routing metric) from
 the bundle's final destination(s) than some other reachable node.
 Designing a system with this capability involves constructing more
 than one routing graph, and is an area of continued research.
 Custody transfer in DTN not only provides a method for tracking
 bundles that require special handling and identifying DTN nodes that
 participate in custody transfer, it also provides a (weak) mechanism
 for enhancing the reliability of message delivery.  Generally
 speaking, custody transfer relies on underlying reliable delivery
 protocols of the networks that it operates over to provide the
 primary means of reliable transfer from one bundle node to the next
 (set).  However, when custody transfer is requested, the bundle layer
 provides an additional coarse-grained timeout and retransmission
 mechanism and an accompanying (bundle-layer) custodian-to-custodian
 acknowledgment signaling mechanism.  When an application does *not*
 request custody transfer, this bundle layer timeout and
 retransmission mechanism is typically not employed, and successful
 bundle layer delivery depends solely on the reliability mechanisms of
 the underlying protocols.
 When a node accepts custody for a bundle that contains the Custody
 Transfer Requested option, a Custody Transfer Accepted Signal is sent
 by the bundle layer to the Current Custodian EID contained in the
 primary bundle block.  In addition, the Current Custodian EID is
 updated to contain one of the forwarding node's (unicast) EIDs before
 the bundle is forwarded.
 When an application requests an ADU to be delivered with custody
 transfer, the request is advisory.  In some circumstances, a source
 of a bundle for which custody transfer has been requested may not be
 able to provide this service.  In such circumstances, the subject
 bundle may traverse multiple DTN nodes before it obtains a custodian.
 Bundles in this condition are specially marked with their Current
 Custodian EID field set to a null endpoint.  In cases where
 applications wish to require the source to take custody of the
 bundle, they may supply the Source Node Custody Acceptance Required

Cerf, et al. Informational [Page 20] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 delivery option.  This may be useful to applications that desire a
 continuous "chain" of custody or that wish to exit after being
 ensured their data is safely held in a custodian.
 In a DTN network where one or more custodian-to-custodian hops are
 strictly one directional (and cannot be reversed), the DTN custody
 transfer mechanism will be affected over such hops due to the lack of
 any way to receive a custody signal (or any other information) back
 across the path, resulting in the expiration of the bundle at the
 ingress to the one-way hop.  This situation does not necessarily mean
 the bundle has been lost; nodes on the other side of the hop may
 continue to transfer custody, and the bundle may be delivered
 successfully to its destination(s).  However, in this circumstance a
 source that has requested to receive expiration BSRs for this bundle
 will receive an expiration report for the bundle, and possibly
 conclude (incorrectly) that the bundle has been discarded and not
 delivered.  Although this problem cannot be fully solved in this
 situation, a mechanism is provided to help ameliorate the seemingly
 incorrect information that may be reported when the bundle expires
 after having been transferred over a one-way hop.  This is
 accomplished by the node at the ingress to the one-way hop reporting
 the existence of a known one-way path using a variant of a bundle
 status report.  These types of reports are provided if the subject
 bundle requests the report using the 'Report When Bundle Forwarded'
 delivery option.

3.11. DTN Support for Proxies and Application Layer Gateways

 One of the aims of DTN is to provide a common method for
 interconnecting application layer gateways and proxies.  In cases
 where existing Internet applications can be made to tolerate delays,
 local proxies can be constructed to benefit from the existing
 communication capabilities provided by DTN [S05, T02].  Making such
 proxies compatible with DTN reduces the burden on the proxy author
 from being concerned with how to implement routing and reliability
 management and allows existing TCP/IP-based applications to operate
 unmodified over a DTN-based network.
 When DTN is used to provide a form of tunnel encapsulation for other
 protocols, it can be used in constructing overlay networks comprised
 of application layer gateways.  The application acknowledgment
 capability is designed for such circumstances.  This provides a
 common way for remote application layer gateways to signal the
 success or failure of non-DTN protocol operations initiated as a
 result of receiving DTN ADUs.  Without this capability, such
 indicators would have to be implemented by applications themselves in
 non-standard ways.

Cerf, et al. Informational [Page 21] RFC 4838 Delay-Tolerant Networking Architecture April 2007

3.12. Timestamps and Time Synchronization

 The DTN architecture depends on time synchronization among DTN nodes
 (supported by external, non-DTN protocols) for four primary purposes:
 bundle and fragment identification, routing with scheduled or
 predicted contacts, bundle expiration time computations, and
 application registration expiration.
 Bundle identification and expiration are supported by placing a
 creation timestamp and an explicit expiration field (expressed in
 seconds after the source timestamp) in each bundle.  The origination
 timestamps on arriving bundles are made available to consuming
 applications in ADUs they receive by some system interface function.
 Each set of bundles corresponding to an ADU is required to contain a
 timestamp unique to the sender's EID.  The EID, timestamp, and data
 offset/length information together uniquely identify a bundle.
 Unique bundle identification is used for a number of purposes,
 including custody transfer and reassembly of bundle fragments.
 Time is also used in conjunction with application registrations.
 When an application expresses its desire to receive ADUs destined for
 a particular EID, this registration is only maintained for a finite
 period of time, and may be specified by the application.  For
 multicast registrations, an application may also specify a time range
 or "interest interval" for its registration.  In this case, traffic
 sent to the specified EID any time during the specified interval will
 eventually be delivered to the application (unless such traffic has
 expired due to the expiration time provided by the application at the
 source or some other reason prevents such delivery).

3.13. 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 bundles for long periods of time.
 For the purposes of this document, we define "flow control" as a
 means of assuring that the average rate at which a sending node
 transmits data to a receiving node does not exceed the average rate
 at which the receiving node is prepared to receive data from that
 sender. (Note that this is a generalized notion of flow control,
 rather than one that applies only to end-to-end communication.)  We
 define "congestion control" as a means of assuring that the aggregate
 rate at which all traffic sources inject data into a network does not

Cerf, et al. Informational [Page 22] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 exceed the maximum aggregate rate at which the network can deliver
 data to destination nodes over time.  If flow control is propagated
 backward from congested nodes toward traffic sources, then the flow
 control mechanism can be used as at least a partial solution to the
 problem of congestion as well.
 DTN flow control decisions must be made within the bundle layer
 itself based on information about resources (in this case, primarily
 persistent storage) available within the bundle node.  When storage
 resources become scarce, a DTN node has only a certain degree of
 freedom in handling the situation.  It can always discard bundles
 which have expired -- an activity DTN nodes should perform regularly
 in any case.  If it ordinarily is willing to accept custody for
 bundles, it can cease doing so.  If storage resources are available
 elsewhere in the network, it may be able to make use of them in some
 way for bundle storage.  It can also discard bundles which have not
 expired but for which it has not accepted custody.  A node must avoid
 discarding bundles for which it has accepted custody, and do so only
 as a last resort.  Determining when a node should engage in or cease
 to engage in custody transfers is a resource allocation and
 scheduling problem of current research interest.
 In addition to the bundle layer mechanisms described above, a DTN
 node may be able to avail itself of support from lower-layer
 protocols in affecting its own resource utilization.  For example, a
 DTN node receiving a bundle using TCP/IP might intentionally slow
 down its receiving rate by performing read operations less frequently
 in order to reduce its offered load.  This is possible because TCP
 provides its own flow control, so reducing the application data
 consumption rate could effectively implement a form of hop-by-hop
 flow control.  Unfortunately, it may also lead to head-of-line
 blocking issues, depending on the nature of bundle multiplexing
 within a TCP connection.  A protocol with more relaxed ordering
 constraints (e.g. SCTP [RFC2960]) might be preferable in such
 circumstances.
 Congestion control is an ongoing research topic.

3.14. Security

 The possibility of severe resource scarcity in some delay-tolerant
 networks dictates that some form of authentication and access control
 to the network itself is required in many circumstances.  It is not
 acceptable for an unauthorized user to flood the network with traffic
 easily, possibly denying service to authorized users.  In many cases
 it is also not acceptable for unauthorized traffic to be forwarded
 over certain network links at all.  This is especially true for
 exotic, mission-critical links.  In light of these considerations,

Cerf, et al. Informational [Page 23] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 several goals are established for the security component of the DTN
 architecture:
  1. Promptly prevent unauthorized applications from having their data

carried through or stored in the DTN.

  1. Prevent unauthorized applications from asserting control over the

DTN infrastructure.

  1. Prevent otherwise authorized applications from sending bundles at a

rate or class of service for which they lack permission.

  1. Promptly discard bundles that are damaged or improperly modified in

transit.

  1. Promptly detect and de-authorize compromised entities.
 Many existing authentication and access control protocols designed
 for operation in low-delay, connected environments may not perform
 well in DTNs.  In particular, updating access control lists and
 revoking ("blacklisting") credentials may be especially difficult.
 Also, approaches that require frequent access to centralized servers
 to complete an authentication or authorization transaction are not
 attractive.  The consequences of these difficulties include delays in
 the onset of communication, delays in detecting and recovering from
 system compromise, and delays in completing transactions due to
 inappropriate access control or authentication settings.
 To help satisfy these security requirements in light of the
 challenges, the DTN architecture adopts a standard but optionally
 deployed security architecture [DTNSEC] that utilizes hop-by-hop and
 end-to-end authentication and integrity mechanisms.  The purpose of
 using both approaches is to be able to handle access control for data
 forwarding and storage separately from application-layer data
 integrity.  While the end-to-end mechanism provides authentication
 for a principal such as a user (of which there may be many), the hop-
 by-hop mechanism is intended to authenticate DTN nodes as legitimate
 transceivers of bundles to each-other.  Note that it is conceivable
 to construct a DTN in which only a subset of the nodes participate in
 the security mechanisms, resulting in a secure DTN overlay existing
 atop an insecure DTN overlay.  This idea is relatively new and is
 still being explored.
 In accordance with the goals listed above, DTN nodes discard traffic
 as early as possible if authentication or access control checks fail.
 This approach meets the goals of removing unwanted traffic from being
 forwarded over specific high-value links, but also has the associated
 benefit of making denial-of-service attacks considerably harder to

Cerf, et al. Informational [Page 24] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 mount more generally, as compared with conventional Internet routers.
 However, the obvious cost for this capability is potentially larger
 computation and credential storage overhead required at DTN nodes.
 For more detailed information on DTN security provisions, refer to
 [DTNSEC] and [DTNSOV].

4. State Management Considerations

 An important aspect of any networking architecture is its management
 of state.  This section describes the state managed at the bundle
 layer and discusses how it is established and removed.

4.1. Application Registration State

 In long/variable delay environments, an asynchronous application
 interface seems most appropriate.  Such interfaces typically include
 methods for applications to register callback actions when certain
 triggering events occur (e.g., when ADUs arrive).  These
 registrations create state information called application
 registration state.
 Application registration state is typically created by explicit
 request of the application, and is removed by a separate explicit
 request, but may also be removed by an application-specified timer
 (it is thus "firm" state).  In most cases, there must be a provision
 for retaining this state across application and operating system
 termination/restart conditions because a client/server bundle round-
 trip time may exceed the requesting application's execution time (or
 hosting system's uptime).  In cases where applications are not
 automatically restarted but application registration state remains
 persistent, a method must be provided to indicate to the system what
 action to perform when the triggering event occurs (e.g., restarting
 some application, ignoring the event, etc.).
 To initiate a registration and thereby establish application
 registration state, an application specifies an Endpoint ID for which
 it wishes to receive ADUs, along with an optional time value
 indicating how long the registration should remain active.  This
 operation is somewhat analogous to the bind() operation in the common
 sockets API.
 For registrations to groups (i.e., joins), a time interval may also
 be specified.  The time interval refers to the range of origination
 times of ADUs sent to the specified EID.  See Section 3.4 above for
 more details.

Cerf, et al. Informational [Page 25] RFC 4838 Delay-Tolerant Networking Architecture April 2007

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 with the
 custody transfer requested delivery option specified.  Retransmission
 state and accounting state may be released upon receipt of one or
 more Custody Transfer Succeeded signals, indicating custody has been
 moved.  In addition, the bundle's expiration time (possibly mitigated
 by local policy) provides an upper bound on the time when this state
 is purged from the system in the event that it is not purged
 explicitly due to receipt of a signal.

4.3. Bundle Routing and Forwarding State

 As with the Internet architecture, we distinguish between routing and
 forwarding.  Routing refers to the execution of a (possibly
 distributed) algorithm for computing routing paths according to some
 objective function (see [JFP04], for example).  Forwarding refers to
 the act of moving a bundle from one DTN node to another.  Routing
 makes use of routing state (the RIB, or routing information base),
 while forwarding makes use of state derived from routing, and is
 maintained as forwarding state (the FIB, or forwarding information
 base).  The structure of the FIB and the rules for maintaining it are
 implementation choices.  In some DTNs, exchange of information used
 to update state in the RIB may take place on network paths distinct
 from those where exchange of application data takes place.
 The maintenance of state in the RIB is dependent on the type of
 routing algorithm being used.  A routing algorithm may consider
 requested 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.
 Bundles may occupy queues in nodes for a considerable amount of time.
 For unicast or anycast delivery, the amount of time is likely to be
 the interval between when a bundle arrives at a node and when it can
 be forwarded to its next hop.  For multicast delivery of bundles,
 this could be significantly longer, up to a bundle's expiration time.
 This situation occurs when multicast delivery is utilized in such a
 way that nodes joining a group can obtain information previously sent
 to the group.  In such cases, some nodes may act as "archivers" that

Cerf, et al. Informational [Page 26] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 provide copies of bundles to new participants that have already been
 delivered to other participants.

4.4. Security-Related State

 The DTN security approach described in [DTNSEC], when used, requires
 maintenance of state in all DTN nodes that use it.  All such nodes
 are required to store their own private information (including their
 own policy and authentication material) and a block of information
 used to verify credentials.  Furthermore, in most cases, DTN nodes
 will cache some public information (and possibly the credentials) of
 their next-hop (bundle) neighbors.  All cached information has
 expiration times, and nodes are responsible for acquiring and
 distributing updates of public information and credentials prior to
 the expiration of the old set (in order to avoid a disruption in
 network service).
 In addition to basic end-to-end and hop-by-hop authentication, access
 control may be used in a DTN by one or more mechanisms such as
 capabilities or access control lists (ACLs).  ACLs would represent
 another block of state present in any node that wishes to enforce
 security policy.  ACLs are typically initialized at node
 configuration time and may be updated dynamically by DTN bundles or
 by some out of band technique.  Capabilities or credentials may be
 revoked, requiring the maintenance of a revocation list ("black
 list", another form of state) to check for invalid authentication
 material that has already been distributed.
 Some DTNs may implement security boundaries enforced by selected
 nodes in the network, where end-to-end credentials may be checked in
 addition to checking the hop-by-hop credentials.  (Doing so may
 require routing to be adjusted to ensure all bundles comprising each
 ADU pass through these points.)  Public information used to verify
 end-to-end authentication will typically be cached at these points.

4.5. Policy and Configuration State

 DTN nodes will contain some amount of configuration and policy
 information.  Such information may alter the behavior of bundle
 forwarding.  Examples of policy state include the types of
 cryptographic algorithms and access control procedures to use if DTN
 security is employed, whether nodes may become custodians, what types
 of convergence layer (see Section 6) and routing protocols are in
 use, how bundles of differing priorities should be scheduled, where
 and for how long bundles and other data is stored, what status
 reports may be generated or at what rate, etc.

Cerf, et al. Informational [Page 27] RFC 4838 Delay-Tolerant Networking Architecture April 2007

5. Application Structuring Issues

 DTN bundle delivery is intended to operate in a delay-tolerant
 fashion over a broad range of network types.  This does not mean
 there *must* be large delays in the network; it means there *may* be
 very significant delays (including extended periods of disconnection
 between sender and intended recipient(s)).  The DTN protocols are
 delay tolerant, so applications using them must also be delay
 tolerant in order to operate effectively in environments subject to
 significant delay or disruption.
 The communication primitives provided by the DTN architecture are
 based on asynchronous, message-oriented communication which differs
 from conversational request/response communication.  In general,
 applications should attempt to include enough information in an ADU
 so that it may be treated as an independent unit of work by the
 network and receiver(s).  The goal is to minimize synchronous
 interchanges between applications that are separated by a network
 characterized by long and possibly highly variable delays.  A single
 file transfer request message, for example, might include
 authentication information, file location information, and requested
 file operation (thus "bundling" this information together).
 Comparing this style of operation to a classic FTP transfer, one sees
 that the bundled model can complete in one round trip, whereas an FTP
 file "put" operation can take as many as eight round trips to get to
 a point where file data can flow [DFS02].
 Delay-tolerant applications must consider additional factors beyond
 the conversational implications of long delay paths.  For example, an
 application may terminate (voluntarily or not) between the time it
 sends a message and the time it expects a response.  If this
 possibility has been anticipated, the application can be "re-
 instantiated" with state information saved in persistent storage.
 This is an implementation issue, but also an application design
 consideration.
 Some consideration of delay-tolerant application design can result in
 applications that work reasonably well in low-delay environments, and
 that do not suffer extraordinarily in high or highly-variable delay
 environments.

6. Convergence Layer Considerations for Use of Underlying Protocols

 Implementation experience with the DTN architecture has revealed an
 important architectural construct and interface for DTN nodes
 [DBFJHP04].  Not all underlying protocols in different protocol
 families provide the same exact functionality, so some additional
 adaptation or augmentation on a per-protocol or per-protocol-family

Cerf, et al. Informational [Page 28] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 basis may be required.  This adaptation is accomplished by a set of
 convergence layers placed between the bundle layer and underlying
 protocols.  The convergence layers manage the protocol-specific
 details of interfacing with particular underlying protocols and
 present a consistent interface to the bundle layer.
 The complexity of one convergence layer may vary substantially from
 another, depending on the type of underlying protocol it adapts.  For
 example, a TCP/IP convergence layer for use in the Internet might
 only have to add message boundaries to TCP streams, whereas a
 convergence layer for some network where no reliable transport
 protocol exists might be considerably more complex (e.g., it might
 have to implement reliability, fragmentation, flow-control, etc.) if
 reliable delivery is to be offered to the bundle layer.
 As convergence layers implement protocols above and beyond the basic
 bundle protocol specified in [BSPEC], they will be defined in their
 own documents (in a fashion similar to the way encapsulations for IP
 datagrams are specified on a per-underlying-protocol basis, such as
 in RFC 894 [RFC894]).

7. Summary

 The DTN architecture addresses many of the problems of heterogeneous
 networks that must operate in environments subject to long delays and
 discontinuous end-to-end connectivity.  It is based on asynchronous
 messaging and uses postal mail as a model of service classes and
 delivery semantics.  It accommodates many different forms of
 connectivity, including scheduled, predicted, and opportunistically
 connected delivery paths.  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.

8. Security Considerations

 Security is an integral concern for the design of the Delay Tolerant
 Network Architecture, but its use is optional.  Sections 3.6.1, 3.14,
 and 4.4 of this document present some factors to consider for
 securing the DTN architecture, but separate documents [DTNSOV] and
 [DTNSEC] define the security architecture in much more detail.

Cerf, et al. Informational [Page 29] RFC 4838 Delay-Tolerant Networking Architecture April 2007

9. IANA Considerations

 This document specifies the architecture for Delay Tolerant
 Networking, which uses Internet-standard URIs for its Endpoint
 Identifiers.  URIs intended for use with DTN should be compliant with
 the guidelines given in [RFC3986].

10. Normative References

 [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
             Resource Identifier (URI): Generic Syntax", STD 66, RFC
             3986, January 2005.

11. Informative References

 [IPN01]     InterPlaNetary Internet Project, Internet Society IPN
             Special Interest Group, http://www.ipnsig.org.
 [SB03]      S. Burleigh, et al., "Delay-Tolerant Networking - An
             Approach to Interplanetary Internet", IEEE Communications
             Magazine, July 2003.
 [FW03]      F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial
             v1.1", Wartham Associates, 2003.  Available from
             http://www.dtnrg.org.
 [KF03]      K. Fall, "A Delay-Tolerant Network Architecture for
             Challenged Internets", Proceedings SIGCOMM, Aug 2003.
 [JFP04]     S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant
             Network", Proceedings SIGCOMM, Aug/Sep 2004.
 [DFS02]     R. Durst, P. Feighery, K. Scott, "Why not use the
             Standard Internet Suite for the Interplanetary
             Internet?", MITRE White Paper, 2002.  Available from
             http://www.ipnsig.org/reports/TCP_IP.pdf.
 [CK74]      V. Cerf, R. Kahn, "A  Protocol for Packet Network
             Intercommunication", IEEE Trans. on Comm., COM-22(5), May
             1974.
 [IGE00]     C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed
             Diffusion: A Scalable and Robust Communication Paradigm
             for Sensor Networks", Proceedings MobiCOM, Aug 2000.

Cerf, et al. Informational [Page 30] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 [WSBL99]    W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley,
             "The Design and Implementation of an Intentional Naming
             System", Proc. 17th ACM SOSP, Kiawah Island, SC, Dec.
             1999.
 [CT90]      D. Clark, D. Tennenhouse, "Architectural Considerations
             for a New Generation of Protocols", Proceedings SIGCOMM,
             1990.
 [ISCHEMES]  IANA, Uniform Resource Identifer (URI) Schemes,
             http://www.iana.org/assignments/uri-schemes.html.
 [JDPF05]    S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy
             to Cope with Failures in a Delay Tolerant Network",
             Proceedings SIGCOMM, 2005.
 [WJMF05]    Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure Coding
             Based Routing in Opportunistic Networks", Proceedings
             SIGCOMM Workshop on Delay Tolerant Networks, 2005.
 [ZAZ05]     W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay
             Tolerant Networks", Proceedings SIGCOMM Workshop on Delay
             Tolerant Networks, 2005.
 [LFC05]     J. Leguay, T. Friedman, V. Conan, "DTN Routing in a
             Mobility Pattern Space", Proceedings SIGCOMM Workshop on
             Delay Tolerant Networks, 2005.
 [AF03]      J. Alonso, K. Fall, "A Linear Programming Formulation of
             Flows over Time with Piecewise Constant Capacity and
             Transit Times", Intel Research Technical Report IRB-TR-
             03-007, June 2003.
 [FHM03]     K. Fall, W. Hong, S. Madden, "Custody Transfer for
             Reliable Delivery in Delay Tolerant Networks", Intel
             Research Technical Report IRB-TR-03-030, July 2003.
 [BSPEC]     K. Scott, S. Burleigh, "Bundle Protocol Specification",
             Work in Progress, December 2006.
 [DTNSEC]    S. Symington, S. Farrell, H. Weiss, "Bundle Security
             Protocol Specification", Work in Progress, October 2006.
 [DTNSOV]    S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant
             Networking Security Overview", Work in Progress, October
             2006.

Cerf, et al. Informational [Page 31] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 [DBFJHP04]  M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra,
             "Implementing Delay Tolerant Networking", Intel Research
             Technical Report IRB-TR-04-020, Dec. 2004.
 [RFC792]    Postel, J., "Internet Control Message Protocol", STD 5,
             RFC 792, September 1981.
 [RFC894]    Hornig, C., "A Standard for the Transmission of IP
             Datagrams over Ethernet Networks", STD 41, RFC 894, April
             1 1984.
 [RFC2960]   Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
             Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
             Zhang, L., and V. Paxson, "Stream Control Transmission
             Protocol", RFC 2960, October 2000.
 [RFC4088]   Black, D., McCloghrie, K., and J. Schoenwaelder, "Uniform
             Resource Identifier (URI) Scheme for the Simple Network
             Management Protocol (SNMP)", RFC 4088, June 2005.
 [S05]       K. Scott, "Disruption Tolerant Networking Proxies for
             On-the-Move Tactical Networks", Proc. MILCOM 2005
             (unclassified track), Oct. 2005.
 [T02]       W. Thies, et al., "Searching the World Wide Web in Low-
             Connectivity Communities", Proc. WWW Conference (Global
             Community track), May 2002.

12. Acknowledgments

 John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe
 Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen
 Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan
 Symington, Andrei Gurtov, Avri Doria, Tom Henderson, Mark Allman,
 Michael Welzl, and Craig Partridge all contributed useful thoughts
 and criticisms to 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.

Cerf, et al. Informational [Page 32] RFC 4838 Delay-Tolerant Networking Architecture April 2007

Authors' Addresses

 Dr. Vinton G. Cerf
 Google Corporation
 Suite 384
 13800 Coppermine Rd.
 Herndon, VA 20171
 Phone: +1 (703) 234-1823
 Fax:   +1 (703) 848-0727
 EMail: vint@google.com
 Scott C. Burleigh
 Jet Propulsion Laboratory
 4800 Oak Grove Drive
 M/S: 179-206
 Pasadena, CA 91109-8099
 Phone: +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 H440
 McLean, VA 22102
 Phone: +1 (703) 983-7535
 Fax:   +1 (703) 983-7142
 EMail: durst@mitre.org
 Dr. Kevin Fall
 Intel Research, Berkeley
 2150 Shattuck Ave., #1300
 Berkeley, CA 94704
 Phone: +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
 Phone: +1 (818) 354-3063
 Fax:   +1 (818) 393-3575
 EMail: Adrian.Hooke@jpl.nasa.gov

Cerf, et al. Informational [Page 33] RFC 4838 Delay-Tolerant Networking Architecture April 2007

 Dr. Keith L. Scott
 The MITRE Corporation
 7515 Colshire Blvd., M/S H440
 McLean, VA 22102
 Phone: +1 (703) 983-6547
 Fax:   +1 (703) 983-7142
 EMail: kscott@mitre.org
 Leigh Torgerson
 Jet Propulsion Laboratory
 4800 Oak Grove Drive
 M/S: 238-412
 Pasadena, CA 91109-8099
 Phone: +1 (818) 393-0695
 Fax:   +1 (818) 354-6825
 EMail: ltorgerson@jpl.nasa.gov
 Howard S. Weiss
 SPARTA, Inc.
 7075 Samuel Morse Drive
 Columbia, MD 21046
 Phone: +1 (410) 872-1515 x201
 Fax:   +1 (410) 872-8079
 EMail: howard.weiss@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. Informational [Page 34] RFC 4838 Delay-Tolerant Networking Architecture April 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 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.
 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, THE IETF TRUST 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Cerf, et al. Informational [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4838.txt · Last modified: 2007/04/10 01:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki