Sunday, November 29, 2009

Delay Tolerant Network - The Evolving Interplanetary Internet

This document describes architecture for delay-tolerant networks, and is a generalization of the architecture designed for the Interplanetary Internet.


A communication system to provide Internet-like services across interplanetary distances in support of deep space exploration. This generalization addresses networks whose operational characteristics make conventional networking approaches become either unworkable or impractical. We define a message-based overlay that exists above the transport layer of the networks on which it is hosted. The draft presents an architectural overview followed by discussions of services, topology, routing, security, reliability, state management, and end-to-end information exchange

Unlike TCP/IP on Earth, the DTN does not assume a continuous end-to-end connection. In its design, if a destination path can't be found, the data packets are not discarded. Instead, each network node keeps custody of the information as long as necessary until it can safely communicate with another node. This is called store-and-forward method.

 
The DTN architecture is conceived to relax most of Internet architecture assumptions, based on a number of design principles that are summarized here:


• 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, and a way to express the useful lifetime of data to allow the network to better deliver data in serving the needs of applications.

No comments:

Post a Comment