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]