Delay-Tolerant Networking Architecture
RFC 4838

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                            V. Cerf
Request for Comments: 4838              Google/Jet Propulsion Laboratory
Category: Informational                                      S. Burleigh
                                                                A. Hooke
                                                            L. Torgerson
                                          NASA/Jet Propulsion Laboratory
                                                                R. Durst
                                                                K. Scott
                                                   The MITRE Corporation
                                                                 K. Fall
                                                       Intel Corporation
                                                                H. Weiss
                                                            SPARTA, Inc.
                                                              April 2007

                Delay-Tolerant Networking Architecture

Status of This Memo

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

Copyright Notice

   Copyright (C) The IETF Trust (2007).

IESG Note

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

Abstract

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

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

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

Table of Contents

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