Delay-Tolerant Networking Architecture
RFC 4838
Document | Type |
RFC - Informational
(April 2007; No errata)
Was draft-irtf-dtnrg-arch (dtnrg RG)
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IRTF | ||
Formats | plain text pdf html bibtex | ||
Stream | IRTF state | (None) | |
Consensus Boilerplate | Unknown | ||
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4838 (Informational) | |
Telechat date | |||
Responsible AD | Lars Eggert | ||
Send notices to | falk@isi.edu, Stephen.Farrell@cs.tcd.ie |
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 ............................................30Show full document text