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 | ||
| RFC Editor Note | (None) | ||
| 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
Show full document text