DTN网络架构.pdf-资料库

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 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 10. Normative References ..........................................30 11. Informative References ........................................30

12. Acknowledgments ...............................................32 Cerf, et al. Informational [Page 2]

RFC 4838 Delay-Tolerant Networking Architecture April 2007 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 Cerf, et al. Informational [Page 3]

RFC 4838 Delay-Tolerant Networking Architecture April 2007 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- 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]): Cerf, et al. Informational [Page 4]

资料库

DTN网络架构.pdf

相关推荐

网络技术

热门标签

最新资料