Internet DRAFT - draft-irtf-dtnrg-arch

draft-irtf-dtnrg-arch



DTN Research Group                                              V. Cerf 
INTERNET-DRAFT                         Google/Jet Propulsion Laboratory 
<draft-irtf-dtnrg-arch-08.txt>                              S. Burleigh 
December 2006                                                  A. Hooke 
Expires June 2007                                          L. Torgerson 
                                         NASA/Jet Propulsion Laboratory 
                                                               R. Durst 
                                                               K. Scott 
                                                  The MITRE Corporation 
                                                                K. Fall 
                                                      Intel Corporation 
                                                               H. Weiss 
                                                           SPARTA, Inc. 
Delay-Tolerant Networking Architecture 
 
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts.   
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress". 
    
   The list of current Internet-Drafts can be accessed at  
   http://www.ietf.org/ietf/1id-abstracts.txt.  The list of Internet-
   Draft Shadow Directories can be accessed at  
   http://www.ietf.org/shadow.html. 
    
   This document represents the consensus of all the active contributors 
   of the IRTF's Delay Tolerant Networking Research Group (DTNRG).  
   Please see http://www.dtnrg.org.  















 
Cerf, et al.              Expires June 2007                  [Page 1] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
    
Abstract 
    
   This document describes an architecture for delay-tolerant and 
   disruption-tolerant networks, and is an evolution of the architecture 
   originally designed for the Interplanetary Internet, a communication 
   system envisioned to provide Internet-like services across 
   interplanetary distances in support of deep space exploration.  This 
   document describes an architecture that addresses a variety of 
   problems with internetworks having operational and performance 
   characteristics that make conventional (Internet-like) networking 
   approaches either unworkable or impractical.  We define a message-
   oriented overlay that exists above the transport (or other) layers of 
   the networks it interconnects.  The document presents a motivation 
   for the architecture, an architectural overview, review of state 
   management required for its operation, and a discussion of 
   application design issues. 




































 
Cerf, et al.              Expires June 2007                   [Page 2] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
Table of Contents 
    
   Status of this Memo................................................1 
   Abstract...........................................................2 
   Table of Contents..................................................3 
   1     Introduction.................................................5 
   2     Why an Architecture for Delay-Tolerant Networking?...........6 
   3     DTN Architectural Description................................7 
         3.1  Virtual Message Switching using Store-and-Forward 
              Operation...............................................7 
         3.2  Nodes and Endpoints.....................................9 
         3.3  Endpoint Identifiers (EIDs) and Registrations...........9 
         3.4  Anycast and Multicast..................................11 
         3.5  Priority Classes.......................................11 
         3.6  Postal-Style Delivery Options and Administrative Records12 
         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 Time Stamps and Time Synchronization...................21 
         3.13 Congestion and Flow Control at the Bundle Layer........22 
         3.14 Security...............................................23 
   4     State Management Considerations.............................24 
         4.1  Application Registration State.........................24 
         4.2  Custody Transfer State.................................25 
         4.3  Bundle Routing and Forwarding State....................25 
         4.4  Security-Related State.................................26 
         4.5  Policy and Configuration State.........................26 
   5     Application Structuring Issues..............................27 
   6     Convergence Layer Considerations for Use of Underlying 
         Protocols...................................................27 
   7     Summary.....................................................28 
   8     Security Considerations.....................................28 
   9     IANA Considerations.........................................28 
   10    Normative References........................................29 
   11    Informative References......................................29 
    















 
Cerf, et al.              Expires June 2007                   [Page 3] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
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. 
    
Release Notes 
    
draft-irtf-dtnrg-arch-00.txt, March 2003:  
   -Revised model for delay tolerant network infrastructure security 
   -Introduced fragmentation and reassembly to the architecture 
   -Removed significant amounts of rationale and redundant text 
   -Moved bundle transfer example(s) to separate draft(s) 
draft-irtf-dtnrg-arch-02.txt, July 2004: 
   -Revised assumptions about reachability within DTN regions 
   -Added management endpoint identifiers for nodes 
   -Moved list of bundle header information to protocol spec document 
draft-irtf-dtnrg-arch-03.txt, July 2005: 
   -Revised regions to become URI schemes 
   -Added discussion of multicast and anycast 
   -Revised motivation/introduction section (2) 
   -Much of the security discussion has moved to the security draft 
   -Updated terminology to match current bundle protocol specification 
draft-irtf-dtnrg-arch-04.txt, November 2005: 
   -Included further terminology updates and minor editing 
draft-irtf-dtnrg-arch-05.txt, March 2006: 
   -Added consensus wording for new IRTF document process proposal 
draft-irtf-dtnrg-arch-06.txt, May 2006: 
   -Incorporated review comments / corrected typos 
   -Clarified terminology with regard to bundles and messages 
   -Changed terminology from "header" to "block" 
draft-irtf-dtnrg-arch-07.txt, October 2006: 
   -Minor edits 
   -ADU fragmented at source has all bundles with same EID/timestamp 
draft-irtf-dtnrg-arch-08.txt, December 2006: 
   -Further refine ADU/bundle & EID/node/endpoint distinction 
   -Added example of reactive fragmentation 
   -Explain how some BSRs are primarily designed for diagnostic purposes 
    






 
Cerf, et al.              Expires June 2007                   [Page 4] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
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 
   environment and those protocols specific to another, and both provide 
   a store-and-forward forwarding service (with the bundle layer 
   employing persistent storage for its store and forward function). 
    
   In a sense, the DTN architecture provides a common method for 
   interconnecting heterogeneous gateways or proxies that employ store-
 
Cerf, et al.              Expires June 2007                   [Page 5] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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: 
    
   - that an end-to-end path between source and destination exists for 
      the duration of a communication session  
   - (for reliable communication) that retransmissions based on timely 
      and stable feedback from data receivers is an effective means for 
      repairing errors 
   - that end-to-end loss is relatively small 
   - that all routers and end stations support the TCP/IP protocols 
   - that applications need not worry about communication performance 
   - that endpoint-based security mechanisms are sufficient for meeting 
      most security concerns 
   - that packet switching is the most appropriate abstraction for 
      interoperability and performance 
   - that selecting a single route between sender and receiver is 
      sufficient for achieving acceptable communication performance 
    
   The DTN architecture is conceived to relax most of these assumptions, 
   based on a number of design principles that are summarized here (and 
   further discussed in [KF03]): 
    
   - Use variable-length (possibly long) messages (not streams or 
      limited-sized packets) as the communication abstraction to help 
      enhance the ability of the network to make good scheduling/path 
      selection decisions when possible. 
   - Use a naming syntax that supports a wide range of naming and 
      addressing conventions to enhance interoperability. 
   - Use storage within the network to support store-and-forward 
      operation over multiple paths, and over potentially long 
      timescales (i.e., to support operation in environments where many 
      and/or no end-to-end paths may ever exist); do not require end-to-
      end reliability. 
   - Provide security mechanisms that protect the infrastructure from 
      unauthorized use by discarding traffic as quickly as possible. 
   - Provide coarse-grained classes of service, delivery options, 
      synchronized sending time stamps and a way to express the useful 
      life of data in order to allow the network to better deliver data 
      in serving the needs of applications. 
 
Cerf, et al.              Expires June 2007                   [Page 6] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
    
   In addition to the principles guiding the design of the bundle layer 
   itself, its use is also guided by a few application design 
   principles: 
    
   - Applications should minimize the number of round-trip exchanges. 
   - Applications should cope with restarts after failure while network 
      transactions remain pending. 
   - 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, also called Application 
   Data Units or ADUs [CT90] of arbitrary length, subject to any 
   implementation limitations. The relative order of ADUs might not be 
   preserved.  ADUs are typically sent by and delivered to 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 

 
Cerf, et al.              Expires June 2007                   [Page 7] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   (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 
   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]. 
    
 
 
Cerf, et al.              Expires June 2007                   [Page 8] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
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. 
    
    
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 
 
Cerf, et al.              Expires June 2007                   [Page 9] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   in a URI is a series of characters constrained by the syntax defined 
   by the scheme.  This portion of the URI is called the scheme-specific 
   part (SSP), and can be quite general.  (See, as one example, the URI 
   scheme for SNMP [RFC4088]).  Note that scheme-specific syntactical 
   and semantic restrictions may be more constraining than the basic 
   rules of RFC 3986.  Section 3.1 of RFC 3986 provides guidance on the 
   syntax of scheme names. 
    
   URI schemes are a key concept in the DTN architecture, and evolved 
   from an earlier concept called regions, which were tied more closely 
   to assumptions of the network topology.  Using URIs, significant 
   flexibility is attained in the structuring of EIDs.  They might, for 
   example, be constructed based on DNS names, or might look like 
   "expressions of interest" or forms of database-like queries as in a 
   directed diffusion-routed network [IGE00] or in intentional naming 
   [WSBL99].  As names, EIDs are not required to be related to routing 
   or topological organization.  Such a relationship is not prohibited, 
   however, and in some environments using EIDs this way may be 
   advantageous. 
    
   A single EID may refer to 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. 
 
Cerf, et al.              Expires June 2007                  [Page 10] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
    
   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 
   must propagate through the network, and may also limit the scope of 
   mapping synchronization requirements to a local topological 
   neighborhood of 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.              Expires June 2007                  [Page 11] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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: 
    
   - Bulk - Bulk bundles are shipped on a "least effort" basis.  No 
      bundles of this class will be shipped until all bundles of other 
      classes bound for the same destination and originating from the 
      same source have been shipped.   
   - Normal - Normal class bundles are shipped prior to any bulk class 
      bundles and are otherwise the same as bulk bundles. 
   - Expedited - Expedited bundles, in general, are shipped prior to 
      bundles of other classes and are otherwise the same.   
    
   Applications specify their requested priority class and data lifetime 
   (see below) for each 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. 
    
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: 
    
   - Custody Transfer Requested - requests sent bundles be delivered 
      with enhanced reliability using custody transfer procedures.  Sent 
 
Cerf, et al.              Expires June 2007                  [Page 12] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
      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. 
    
   - 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). 
    
   - 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". 
    
   - 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. 
    
   - 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. 
    
   - 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. 
    
   - 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. 
    
   - 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: 
 
Cerf, et al.              Expires June 2007                  [Page 13] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
    
   - Confidentiality Required - requires the subject ADU be made secret 
      from parties other than the source and the members of the 
      destination EID. 
     
   - 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. 
    
   - 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).   
    
   The following BSRs are currently defined (also see [BSPEC] for more 
   details): 
    
   - Bundle Reception - sent when a bundle arrives at a DTN node.  
      Generation of this message may be limited by local policy. 
    
   - 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. 
    
   - 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. 
    
   - 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. 
    
 
Cerf, et al.              Expires June 2007                  [Page 14] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   - 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. 
    
   - 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: 
    
   - 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. 
    
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: 
 
  - 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). 
   
  - 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. 
   
  - 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. 
 
Cerf, et al.              Expires June 2007                  [Page 15] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   
  - Source EID - EID of the source (the first sender). 
 
  - Destination EID - EID of the destination (the final intended 
     recipient(s)). 
 
  - 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. 
   
  - 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. 
    
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) [JPF04].  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). 
    

 
Cerf, et al.              Expires June 2007                  [Page 16] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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: 
    
   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). 
    
 
Cerf, et al.              Expires June 2007                  [Page 17] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   Intermittent - Predicted Contacts 
    
   Predicted contacts are based on no fixed schedule, but rather are 
   predictions of likely contact times and durations based on a history 
   of previously observed contacts or some other information.  Given a 
   great enough confidence in a predicted contact, routes may be chosen 
   based on this information.  This is an active research area, and a 
   few approaches having been proposed [LFC05]. 
    
3.9 Fragmentation and Reassembly 
    
   DTN fragmentation and reassembly is designed to improve the 
   efficiency of bundle transfers by ensuring that contact volumes are 
   fully utilized and by avoiding re-transmission 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.   
      
   The reactive fragmentation capability is not required to be available 
   in every DTN implementation, as it requires a certain level of 
 
Cerf, et al.              Expires June 2007                  [Page 18] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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 re-assemble 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 re-transmitting 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 
   are required by the DTN architecture to accept custody transfers, so 
   it is not a true 'hop-by-hop' mechanism.  For example, some nodes may 
   have sufficient storage resources to sometimes act as custodians, but 
   may elect to not offer such services when congested or running low on 
   power. 
    

 
Cerf, et al.              Expires June 2007                  [Page 19] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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 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 
 
Cerf, et al.              Expires June 2007                  [Page 20] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   source that has requested to receive expiration BSRs for this bundle 
   will receive an expiration report for the bundle, and possibly 
   conclude (incorrectly) 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 implemented by applications themselves in 
   non-standard ways. 
    
3.12 Time Stamps and Time Synchronization 
    
   The DTN architecture depends on time synchronization among DTN nodes 
   (supported by external, non-DTN protocols) for four primary purposes: 
   bundle and fragment identification, routing with scheduled or 
   predicted contacts, bundle expiration time computations, and 
   application registration expiration. 
    
   Bundle identification and expiration are supported by placing a 
   creation timestamp and an explicit expiration field (expressed in 
   seconds after the source time stamp) in each bundle .  The 
   origination time stamp 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 

 
Cerf, et al.              Expires June 2007                  [Page 21] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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 
   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. 
 
Cerf, et al.              Expires June 2007                  [Page 22] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
    
   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, 
   several goals are established for the security component of the DTN 
   architecture: 
    
  - Promptly prevent unauthorized applications from having their data 
     carried through or stored in the DTN 
  - Prevent unauthorized applications from asserting control over the 
     DTN infrastructure 
  - Prevent otherwise authorized applications from sending bundles at a 
     rate or class of service for which they lack permission 
  - Promptly discard bundles that are damaged or improperly modified in 
     transit 
  - Promptly detect and de-authorize compromised entities 
   
   Many existing authentication and access control protocols designed 
   for operation in low-delay, connected environments may not perform 
   well in DTNs.  In particular, updating access control lists and 
   revoking ("blacklisting") credentials may be especially difficult.  
   Also, approaches that require frequent access to centralized servers 
   to complete an authentication or authorization transaction are not 
   attractive.  The consequences of these difficulties include delays in 
   the onset of communication, delays in detecting and recovering from 
   system compromise, and delays in completing transactions due to 
   inappropriate access control or authentication settings.   
    
   To help satisfy these security requirements in light of the 
   challenges, the DTN architecture adopts a standard but optionally 
 
Cerf, et al.              Expires June 2007                  [Page 23] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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 
   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.).  
    
 
Cerf, et al.              Expires June 2007                  [Page 24] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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. 
    
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. 
    

 
Cerf, et al.              Expires June 2007                  [Page 25] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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 
   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 

 
Cerf, et al.              Expires June 2007                  [Page 26] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   and for how long bundles and other data is stored, what status 
   reports may be generated or at what rate, etc. 
    
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 
   basis may be required.  This adaptation is accomplished by a set of 
   convergence layers placed between the bundle layer and underlying 
 
Cerf, et al.              Expires June 2007                  [Page 27] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   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. 
 
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]. 
    
    
    

 
Cerf, et al.              Expires June 2007                  [Page 28] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
10 Normative References 
    
   [RFC3978]   Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 
   3978, March 2005. 
    
   [RFC3979]   Bradner, S., "Intellectual Property Rights in IETF 
   Technology", BCP 79, RFC 3979, March 2005. 
    
   [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource 
   Identifier (URI): Generic Syntax", STD 66, RFC 3986, Jan 2005. 
 
    
11 Informative References 
    
   [IPN01] 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. 
    
   [WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley, 
   "The Design and Implementation of an Intentional Naming System", 
   Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999. 
     
   [CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a 
   New Generation of Protocols", Proceedings SIGCOMM, 1990. 
    
   [ISCHEMES] http://www.iana.org/assignments/uri-schemes.html 
    
   [JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy to 
   Cope with Failures in a Delay Tolerant Network", Proceedings SIGCOMM, 
   2005. 
    
 
Cerf, et al.              Expires June 2007                  [Page 29] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   [WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure Coding 
   Based Routing in Opportunistic Networks", Proceedings SIGCOMM 
   Workshop on Delay Tolerant Networks, 2005. 
    
   [ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay Tolerant 
   Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks, 
   2005. 
    
   [LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a Mobility 
   Pattern Space", Proceedings SIGCOMM Workshop on Delay Tolerant 
   Networks, 2005. 
    
   [AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of Flows 
   over Time with Piecewise Constant Capacity and Transit Times", Intel 
   Research Technical Report IRB-TR-03-007, June 2003. 
    
   [FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable 
   Delivery in Delay Tolerant Networks", Intel Research Technical Report 
   IRB-TR-03-030, July 2003. 
    
   [RFC2960] R. Stewart et. al., "Stream Control Transmission Protocol", 
   RFC 2960, Oct. 2000. 
    
   [BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification", 
   draft-irtf-dtnrg-bundle-spec-08.txt, Work in Progress, December 2006. 
    
   [DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security 
   Protocol Specification", draft-irtf-dtnrg-bundle-security-02.txt, 
   Work in Progress, October 2006. 
    
   [DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant 
   Networking Security Overview", draft-irtf-dtnrg-sec-overview-02.txt, 
   Work in Progress, October 2006. 
    
   [DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra, 
   "Implementing Delay Tolerant Networking", Intel Research Technical 
   Report IRB-TR-04-020, Dec. 2004. 
    
   [RFC894] C. Hornig, "Standard for the Transmission of IP Datagrams 
   over Ethernet Networks", RFC 894, Apr. 1984. 
    
   [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. 
    
    
    
    
 
 
Cerf, et al.              Expires June 2007                  [Page 30] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
Authors' Addresses 
    
   Dr. Vinton G. Cerf 
   Google Corporation 
   Suite 384 
   13800 Coppermine Rd. 
   Herndon, VA 20171 
   Telephone +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 
   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 H440 
   McLean, VA 22102 
   Telephone +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 
   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 H440 
   McLean, VA 22102 
   Telephone +1 (703) 983-6547 
   FAX +1 (703) 983-7142 
   Email kscott@mitre.org 
    
 
Cerf, et al.              Expires June 2007                  [Page 31] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   Leigh Torgerson 
   Jet Propulsion Laboratory 
   4800 Oak Grove Drive 
   M/S: 238-412 
   Pasadena, CA 91109-8099 
   Telephone +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 
   Telephone +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. 
 
Copyright Notice 
    
   Copyright (C) The Internet Society (2006).  This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
Disclaimer of Validity 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
Intellectual Property 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 

 
Cerf, et al.              Expires June 2007                  [Page 32] 


Internet Draft       draft-irtf-dtnrg-arch-08.txt        December 2006 
 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org. 
    
    











































 
Cerf, et al.              Expires June 2007                  [Page 33]