, Research Institute for Advanced Computer Science/NASA Ames
Pages: pp. 4-5
The planets have aligned. This is usually of more interest to astrologers than engineers, but the current planetary alignment brings Mars closer to Earth than it has been in almost 60,000 years, creating an excellent opportunity to explore the red planet. Several probes are now shooting toward Mars, including the British Beagle 2 lander and NASA's pair of Mars Exploration Rovers, Spirit and Opportunity.
We sort of understand how to get things to Mars, but we're far from being able to bring them back. This implies that landers, rovers, and satellites must send their scientific results by radio signal. Currently, the prominent backbone for the radio reception is the Deep Space Network (DSN; http://deepspace.jpl.nasa.gov/dsn/), an international network of antennas, anchored by communication facilities in California, Spain, and Australia. The DSN allows the tracking of spacecraft, transmittal of commands, and downloading of the experimental results. The DSN is backed up by a ground-based network of communication links and storage devices. By and large, each new project makes its own choices and implementations about the structures of these communications and systems.
The current status of space networking echoes the state of planetary networking before the Internet, where technology was customarily reinvented and customized according to different organizations' requirements. The owners of private networks found increasing need for interoperability and tired of wheel reinvention; the Internet provided the standards for interchange. Space missions, faced with the need to be better, faster, and cheaper, and cognizant of the desirability of quickly making their results available to an Internet-savvy world, would like Mars (and the rest of outer space) to look to applications just like any other Net-addressable node. That is, we'd like to be able to send packets to the spectrometer as mössbauer.spirit.mars.sol the same way we query the stock ticker at Yahoo.com.
Unfortunately, the Internet's usability relies on several properties that aren't true of deep-space communications. Internet protocols are conversational; many steps in the protocol require an immediate acknowledgement. The Internet assumes that there is a continuous, bidirectional, end-to-end path between communicating entities. Sadly, light can take tens of minutes to get from here to Mars, and in the time that a signal is being transmitted, the planet can rotate or revolve out of communication range, perhaps for days. Internet protocols assume short and relatively constant communication delays, but for deep-space communication there doesn't seem to be any way to overcome the sluggishness of light. Internet protocols are optimized for communications that almost always work, but faint, distant, solar-powered radio signals have high error rates. 1 (See www.ipnsig.org/techinfo.htm.)
The Interplanetary Internet (IPN) work hypothesizes a set of conventional, planetary internets connected by a deep-space backbone. Unlike real-time TCP/IP protocols, nodes on the IPN backbone will "bundle" communications together in a store-and-forward fashion. An IPN node will take responsibility (until some more distant time-out) for forwarding its data, deleting it from persistent storage only after receiving the next node's acknowledgement of receipt. Serving as surrogates for end-to-end sources and destinations, bundle layers will terminate transport protocols.
Addressing will also change on an interplanetary scale. Current TCP/IP thinks nothing of sending a DNS enquiry to find an IP address, and then opening a session on that IP. This scheme is less practical when the DNS request itself takes half an hour. In IPN, addresses have two parts: the backbone IPN node and a local address within the internet served by that node. The local address will not be resolved remotely. The IPN will be responsible for getting the request to the IPN node, which can use conventional addressing to route the request around its planet. IPN thus steps away from IP's route-free addressing; half the address is a well-known regional destination, while the other half is still route-free.
Interplanetary networks might seem exotic, but many conventional environments share characteristics with the IPN. Transient connectivity, limited power, low bandwidth, noisy channels, and lack of real-time end-to-end paths characterize mobile, battery-powered devices like untethered phones, computers, and PDAs; emergency and battlefield conditions; sensor Webs; and vehicles in motion. The principles of the IPN (except, perhaps, the need to include the planet and solar system in addresses) carry over to the more general concept of research on delay-tolerant networks (DTN).
The end-to-end argument is a network-design principle, first elaborated by Saltzer, Reed, and Clark, that argues that there's rarely value in placing functionality at a communication system's lower levels. 2,3 For reliable systems, activities such as error recovery, duplicate message suppression, failure recovery, message ordering, and conversational acknowledgments all need replication by the application. There's seldom any point in expending a lot of energy replicating this functionality within the network.
While Saltzer and colleagues were considerably more cautious in their original arguments (allowing an exception for performance), many have elevated the end-to-end argument to a religious principle: networks should be dumb and solely concerned with the simple-minded forwarding of packets. The lovely thing about IPN is that it's such a wonderful counterexample to the naive application of the end-to-end principle. A dumb network doesn't work on noisy, thirty-minute communications, and until someone figures out how to get the information between Mars and Earth faster than the speed of light, a dumb network won't work. The IPN is an important reminder that the end-to-end argument is an engineering principle, and like all engineering principles, it's based on certain assumptions and is useful only when those assumptions are valid.
One day, you'll reach me at email@example.com.