Inter Planetary Network - Online Article


The Internet is slated to go over and above this world, the first target being Mars, to be followed by Jupiter and its moon, Europa. This idea of taking the Internet to the space comes from the need for a low cost and high reliability inter-planetary network.

This document describes the Interplanetary Internet: a communication system to provide Internet-like services across interplanetary distances in support of deep space exploration. Our approach, which we refer to as bundling, builds a store-and-forward overlay network above the transport layers of underlying networks. Bundling uses many of the techniques of electronic mail, but is directed toward interprocess communication, and is designed to operate in environments that have very long speed-of-light delays. We partition the Interplanetary Internet into IPN Regions, and discuss the implications that this has on naming and routing. We discuss the way that bundling establishes dialogs across intermittently connected internets, and go on to discuss the types of bundle nodes that exist in the interplanetary internet, followed by a discussion of security in the IPN, a discussion of the IPN backbone network, and a discussion of remote deployed internets.

Natural Evaluation

The exploration of space began with naked-eye observations of the stars and moon. In more recent centuries, this exploration was aided by new Earth-based technologies such as optical and radio telescopes. Even more recently, we have placed observing resources into near Earth orbit, such as the Hubble Space Telescope. We have also sent robotic missions to other parts of the Solar system for a closer look.

It is the latter activity -- the current exploration of the Solar System by robotic means and possibly later by missions crewed by people -- that motivates our interest in an Interplanetary Internet. The new technology of the terrestrial Internet needs to be extended into space. We believe that the creation and adoption of Internet friendly standards for space communication will enhance our ability to build a common interplanetary communication infrastructure. We think this infrastructure will be needed to support he expansion of human intelligence throughout the Solar System. The current terrestrial Internet and its technology provide a robust basis to support these missions in an efficient and scalable manner.

Although many missions during the last 40 years of space exploration have by necessity provided a substantial portion of their own communication resources, a significant amount of shared infrastructure is already in place. For example, the multi-mission Deep Space Network (DSN) provides a complex of large-diameter (up to 70-meter) tracking and data acquisition dishes at three points on the Earth's surface, each about 120 degrees from each other. Similarly, the Tracking and Data Relay Satellite System (TDRSS) and a global network of small ground tracking stations are used to relay data to and from many near-Earth missions.


You can talk to almost anyone, in any corner of the world, almost instantly because of the Internet and other advances in electronic communication. Scientists and space explorers now are looking for a way to communicate almost instantly beyond Earth. The next phase of the Internet will take us to far reaches of our solar system, and lay the groundwork for a communications system for a manned mission to Mars and planets beyond.

Dr. Vinton Cerf, often touted as the "father of the Internet", spoke recently on the current status of the Interplanetary Internet (IPN). The IPN is a proposed method for linking together Earth and the ever-increasing number of space probes we have sent out. Put more simply, it is the means whereby Earth's nervous system expands outwards across the solar system - and beyond.

The objective of the Interplanetary Internet project is to define the architecture and protocols necessary to permit interoperation of the Internet resident on Earth with other remotely located internets resident on other planets or spacecraft in transit.

While the Earth's Internet is basically a "network of connected networks", the Interplanetary Internet may therefore be thought of as a "network of disconnected Internets". Inter-working in this environment will require new techniques to be developed.

The IPN Operating Environment

There are a number of fundamental differences between the environments for terrestrial communications and those we envision for the IPN. These differences include delay, low and asymmetric bandwidth, intermittent connectivity, and a relatively high bit error rate. Taking these into account affects the entire model for communicating; shifting us from the "telephony" model implicit in current Internet communications to the "Postal", or "Pony Express," model. We will first therefore describe the environmental differences between terrestrial communications and the IPN and gives a brief accounting of why the standard Internet protocol for reliable transport, CP, is unsuitable for end-to-end communications in the IPN.

  • SPECIAL EQUIPMENTS: The first difference is that communicating over interplanetary distances currently requires special equipment (large antennas, high performance receivers, etc.). For most deep-space missions, even non-NASA ones, these are currently provided by NASA's Deep Space Network (DSN). The communication resources of the DSN are currently oversubscribed and will probably continue to be so in the future. While studies have been done as to the feasibility of upgrading or replacing the current DSN, the number of deep space missions will probably continue to grow faster than the terrestrial infrastructure needed to support them, making over-subscription a persistent problem.
  • DELAY: The most obvious difference between communicating between points on Earth and communicating between planets is the delay. While roundtrip times in the terrestrial Internet range from milliseconds to a few seconds, round-trip times to Mars range from 8 to 40 minutes, depending on the planet's position, and round-trip times between Earth and Europa run between 66 and 100 minutes.
  • LOW & ASSYMETRIC BANDWIDTH: The combined effects of large distances, the expense and difficulty of deploying large antennas to distant planets, and the difficulty in generating power in space all mean that the available bandwidth for communications in the IPN will likely be modest compared to terrestrial systems. Data rates on the order of hundreds of kilobits per second to a few megabits per second will probably be the norm for the next few decades. Another characteristic prevalent in today's deep-space missions is bandwidth asymmetry, where data is transmitted at different rates in different directions. Current missions are usually designed with a much higher data return rate (from space to Earth) than command rate. The reason for the asymmetry is simple: nobody ever wanted a high-rate command channel, and, all else being equal, it was deemed better to have a more reliable command channel than a faster one. This design choice has led to data rate asymmetries in excess of 100:1, sometimes approaching 1000:1. A strong desire for a very robust command channel will probably remain, so that any transport protocol designed for use in the IPN will need to function with a relatively low bandwidth outbound channel to spacecraft / Landers.
  • HIGH BIT ERROR RATE: The difficulties of generating power on and around other planets will also result in relatively high bit error rates. Current deep-space missions operate with very high bit error rates (on the order of 10e- 1, or one error in ten bits) that are then improved using heavy coding. The tradeoffs between coding, bit error rate, and reliability requirements will need to be reexamined in the context of the IPN.
  • INTERMITTENT CONNECTIVITY: Finally, interplanetary communications will, at least in the near future, be characterized by intermittent connectivity between nodes. As satellites or moons pass behind planets, and as planets pass behind the sun as seen from Earth, we lose the ability to communicate with them. This effect adds to the delays experienced by packets, and could push queuing delays to several weeks or a month if the source and destination are in opposition (on opposite sides of the sun). Inter-layer signaling, especially from the link layer to provide notifications of such breaks in connectivity, will probably be required.

We see the IPN growing outwards from Earth as we explore more and more planets, moons, asteroids, and possibly other stars. Thus there will always be a fringe to the fabric of the IPN, an area without a rich communications infrastructure. As a result, the data rate, connectivity, and error characteristics mentioned above will probably always be an issue somewhere in the IPN. For the more highly developed core areas of the IPN, it is interesting to note that delay is the only truly immutable characteristic that differentiates the IPN from terrestrial communications. Data rates, intermittent connectivity, and bit error rate can all be mitigated or eliminated by adding additional infrastructure, in theory if not in practice. Additional infrastructure can also mitigate the scheduling and queuing delays mentioned above, but the propagation delays will remain unless and until we find a way to transmit information faster than the speed of light.

These environmental characteristics: long delays, low and asymmetric bandwidth, intermittent connectivity, and relatively high error rate make using unmodified TCP/IP for end to end communications in the IPN infeasible.

A "Postal" Communications Model

We have concluded that the standard Internet protocols should be essentially "terminated" at the Interplanetary Gateways and the information payloads conveyed through a new set of protocols better suited to the long distances, variable delays and asymmetric data rates of the interplanetary backbone network. In essence, the design is analogous to a kind of postal relay system in which messages are delivered to the intermediate Interplanetary Gateways, extracted from their standard Internet protocols, and encapsulated in new link and transport protocols to be forwarded to the next IPN gateway and ultimately into the target internet.

Internet electronic mail already works in this fashion but the transfer of files, the operation of the World Wide Web, and remote interactive applications do not fit into this model directly. There are circumstances under which researchers on planet Earth do need an ability to interact with remote devices, for example to steer wheeled robotic vehicles around on the surface. But because of the enormous round-trip delays, such systems must work very indirectly. For example, to steer the Mars Pathfinder rover, one sends instructions about intermediate points that the robot must steer past. This is analogous to automatic airplane pilots that are given a series of coordinates through which to pass. In effect, a planned itinerary is sent and the robot vehicle executes the plan, dealing with local conditions as required.

The "store-and-forward" nature of this communication method is reminiscent of bucket brigades, except that the contents of the buckets are actually the payloads (i.e. data) of the applications that utilize the network. The concept of "custody" is important in such a system. A sender does not relinquish a copy of a transmission until it is sure that the next in line has successfully received it.

IPN Architectural Overview


We now consider five broad areas that represent areas of significant research in the Interplanetary Internet architecture:

  • The communication conducted between independent internets (termed "Inter-internet dialogs").
  • The architecture and functions of the unique nodes of the Interplanetary Internet.
  • A security architecture for meeting anticipated data and infrastructure protection needs.
  • The issues in developing a stable backbone network for the Interplanetary Internet.
  • The issues in deploying internets on remote planets, asteroids, and spacecraft.

Inter - Internet Dialogs

This section first presents four principles that guide the design of the Interplanetary Internet. In doing so, we introduce the concept of the "bundle" layer, a protocol layer providing end-to-end service in the IPN.

Administrator & Routing Parts

In the (terrestrial) Internet, names are administrative in nature, and are hierarchically organized. The Domain Name System (DNS) uses a highly distributed database to translate the name to a numeric address, and addresses are the common medium used throughout the network for reference. This scheme has worked well in the Internet, but the emergence of network address translators and other partitioning mechanisms have begun to cause some problems with this scheme.

One key problem in the design of an Interplanetary Internet is identifying the communicating endpoints. If a common, solar system-wide IP address convention were adopted, then every component of the system would need to be upgraded on a common timescale to preserve the commonality of the address space. The current concept is that rather than have a single address space across the entire Solar System end point identifiers comprise a two-part name. One part of the name (the routing part) gets the bundle delivered to a remote destination "region" of the Interplanetary internet. The second part of the name (the administrative part) contains the information required to deliver to one or more local destinations. Thus for Mars operations the routing part of the name will be used to move the bundle across the Deep Space backbone to the entry gateway on the appropriate region on Mars, where the administrative part of the name comes into play and identifies the local recipient(s) on the Martian internet.

It is necessary and sufficient that the administrative portion of an IPN name be resolvable to a useful address within its IPN Region. We are currently treating the structure of the routing part of the name in a manner similar to the structure of DNS names: the name space of the routing part is a tree of text labels separated by "dots," with the root node of the space having a null label. We denote a name in the IPN in the following manner: {administrative part, routing part}. So, if "earth.sol" were an IPN Region encompassing the entire Earth, the web site for the Internet Society's IPN Special Interest Group would be {, earth.sol}.

In order that any node in the IPN be able to send data to any other node, the routing part of the name must be interpretable everywhere. That is, any IPN node, when confronted with any valid IPN Region name, must be able to identify a transport layer destination that moves the data toward that region.

Bundle Layer & Bundle Protocol

In the IPN, we cannot ever assume that there is direct connectivity between source and destination. Thus depending on the schedules of the nodes involved and the possibility of high-priority interrupt traffic, the nodes that make up the IPN may have to buffer data for hours, days, or weeks before it can be forwarded. Also, the highly varying communications environments that will make up the IPN, ranging from optical fiber on Earth to wireless communications around Mars, to the long-haul links of the backbone, suggest that different transport protocols will be needed for the different environments. It makes sense, therefore, for the IPN nodes to terminate the transport-layer protocols used in the respective IPN regions, holding data at a higher layer before forwarding it on, possibly using a different transport-layer protocol.


We call this higher layer the "bundle layer," and the protocol used to send data between the various nodes of the IPN the "bundle protocol." The term "bundle" is used to connote the store-and forward aspect of communications where as much interactivity as possible has been distilled out of the communication. This protocol is also known by another name as Parcel Transfer Protocol. A bundle file transfer request, for example, might contain the user's authentication (login/password, e.g.), the location of the file to get, and where that file should be delivered in the requester's IPN domain. All of this information would be transmitted as one atomic "bundle," and the requested file would be returned. We use the term "bundle" rather than "transaction" to avoid notions of two-phase and three-phase commitment that are commonly associated with transaction processing.

In traditional networking terminology it is generally the transport layer protocol that operates end-to-end. Since IPN nodes terminate transport layer protocols in order to buffer data and to enable them to use a transport protocol appropriate to the IPN region through which data will be sent, it is the bundle layer in the IPN that operates end-to-end.

Figure 1 illustrates the progression of a bundle of data through the Interplanetary Internet, from its source at host "A" to the destination at host "E." Custody transfers are indicated by asterisks (*), and occur at B, C, D, and E. Host "A" initiates the bundle transfer, and the bundle is transferred using internet protocols (i.e., TCP and IP) to bundle node "B", which serves as the gateway between the left-hand internet and the interplanetary backbone. The box icon indicates that custody of the bundle is transferred to that gateway. When conditions permit, the bundle is forwarded on to the next hop in the store-and-forward chain. In this case the next hop is another host within the interplanetary backbone network: host "C".

Also illustrated in Figure 1 is the notion of a "return receipt" sent by the ultimate destination of the data back to the source. This is an optional service, much like a return receipt within the postal system. The return receipt is forwarded in exactly the same manner as the original data is.


Custody Transfers

Many aspects of this mode of data transfer resemble the postal system, or even the Pony Express. The source depends on the store and- forward nodes in the chain to operate on its behalf to deliver data that may not be retained at the source. Source notification that the destination has received the data is optional, and there is no guarantee or even any firm expectation on the part of the source about when the data will be delivered.

IPN Nodes

Nodes within the IPN have a number of responsibilities. As members in a store-and-forward chain, they have the responsibility for resource allocation to support bundle transfers. These resources include, among other things, buffer space and transmission capacity. Additionally, IPN nodes have the responsibility of actually executing the bundle transfer. Reliability requirements for bundle transfers are specified by the using application, and include both reliable and unreliable transfers (possibly with some intermediate, or partial, reliability services). The IPN nodes are responsible for using whatever reliability mechanisms exist in the underlying (transport and- below) layers, and augmenting those mechanisms as necessary to effect the required reliability. Finally, IPN nodes are responsible for routing bundles between IPN domains. IPN nodes may depend upon the services of the local internets (or the IPN backbone) for intra-domain routing.

Types of IPN Nodes

We identify three grades of IPN functional capability. In order of increasing scope, they are: agent capability, relay capability, and gateway capability. All IPN nodes are able to act as bundle agents; some bundle agents are additionally able to act as IPN relays; some IPN relays are additionally able to act as IPN gateways.

  • Bundle agents build and consume bundles. These could be standalone proxy devices or could be an operating system service collocated with an application. The endpoints of an end-to-end bundle transmission need not be any more than bundle agents, though they may additionally have relay or even gateway capability.
  • IPN Relays receive bundles and forward them toward their destinations, either within or between IPN regions.
  • IPN Gateways reside at the interface between IPN regions. The IPN gateways perform routing between the IPN regions.

Security in the IPN

We do not have a detailed list of security requirements for the Interplanetary Internet, primarily because there currently aren't any "users" of the IPN and few, if any, of the potential users have given enough thought to security to commit to a set of security "requirements". However, we know that the Interplanetary Internet's bandwidth resources will be precious. We can also safely assume that the IPN will be a prized hacker's target (at least from Earth). We can also envision that there will be precious, private data flowing across the IPN. As a result, we assume that various security mechanisms and services will be required to provide protection for the bundles traversing the IPN and for the IPN infrastructure itself.

The security mechanisms assumed to be required for the IPN are:

Access control

Access controls will be required because the IPN's space-based assets will have limited resources available and because it will be a likely target from a hacking perspective. By limiting access to the IPN resources, we limit the availability of the IPN to only those users who require its services and do not allow it to be overburdened by those who are not authorized to access the IPN services.


Authentication of identity will be required to perform access control mediation. To allow or disallow access to the IPN, an assured identity of the source of the network traffic will be needed. The identity might be of an individual (e.g., a payload principal investigator) or a location (e.g., a science payload control center or a spacecraft control center).

Data integrity

Data integrity will be required to ensure that data received across the IPN is the same data that was originally sent. This is true from both an IPN infrastructure perspective (e.g., management data) as well as from a user's perspective (e.g., science data, command sequences). Data integrity assures that any unauthorized modification of the data will be detectable by the receiver.

Data privacy

Data privacy will be required to ensure that only those who are authorized to obtain data traversing the IPN or destined to/from the IPN infrastructure will be able to do so. This mechanism is also known as confidentiality.

In the network security community, there are two well-known security paradigms: hop-by-hop security (also known as link security) and endto- end security. In the hop-by-hop paradigm, the data to be transmitted over the network is protected on a hop-by-hop basis. That is, the data is protected at its source, but in order to be routed to its final destination, it must be unprotected at a trusted routing point (e.g., a ground-based gateway, an IPN gateway) in order to be examined for onward routing. A negative aspect of this security paradigm is that, depending on how the protection is applied; the data might be completely exposed while in the gateway (hence the term trusted gateway). This means that the data is potentially vulnerable to unauthorized modification and unauthorized disclosure. In End to End security the data is protected at its source and is not unprotected until it reaches its destination. But this is not possible in this case of IPN.

Current Internet security protocols often require a series of handshakes" wherein computers certify one another's identify and permissions with a series of back and forth messages before allowing data to be sent. Since two-way communications are somewhat impractical between planets - or at least time and resource consuming - different approaches will be needed to assure security. The Secure Sockets Layer (SSL) protocol currently used for financial transactions and some of the protocols used to secure email are possible paths to emulate in providing security for IPN routing of data.

A Stable Backbone for the IPN

Just as the performance and capability of the terrestrial Internet are largely determined by the capacity and stability of its backbone links, so will the performance and capability of the Interplanetary Internet depend in large part on the capacity and stability of the interplanetary backbone.

By "backbone" we mean a set of high-capacity, high-availability links between points of access to high-activity subnets. In the terrestrial Internet, backbone links are typically between the high activity subnets or cities such as Houston and Chicago. In the Interplanetary Internet, the backbone links will be between the high activity "subnets" for planets, such as Earth and Mars.

Backbone Design Considerations

The differences described above imply two general constraints on the design of the interplanetary backbone.

  1. Bandwidth is not free, or even cheap. Reliable delivery cost per bit will be far higher across the interplanetary backbone than across any terrestrial backbone, so bandwidth must be thoughtfully allocated. Both retransmission and forward error correction coding contribute to reliable delivery, but both cost bandwidth; we must seek a balance between the two that minimizes overall overhead.
  2. Interactive protocols don't work, at least not well. Negotiation _ connection establishment, flow control, congestion control _ can easily take so long as to consume all available transmission time. Reliable, in-order stream delivery can be so severely delayed by retransmission latency as to be operationally useless.

Deployed Internets in the IPN

We differentiate between two types of networks in the IPN: the long haul backbone and deployed internets. The long haul backbone, described in the previous section, is characterized by long propagation times, due to the great physical separation among the communicating elements. Its protocols are designed to operate efficiently in long-delay, intermittent-connectivity environments.

We designate a network to be a "deployed internet" if it meets the following criteria

  • It has connectivity to an interplanetary gateway, and through that gateway can reach the interplanetary backbone or other deployed networks.
  • It has a communication environment that doesn't inherently preclude the use of (possibly enhanced) internet protocols.
  • It uses the Domain Name space as a common means of referencing objects and systems across deployed internets.


The potential applications of a InterPlanetary Internet extend well beyond the management of space missions. People who surf the Internet today and tap websites in extreme locations such as Antarctica may some day be able to communicate to web or ftp servers on Martian microsatellites to request data directly from Mars. And that's just the beginning. Eventually there will be web servers on the International Space Station, on (or above) the Moon and other planets, and other regions of the solar system. We've already watched live images from webcams bolted onto the side of rockets as they lift off from NASA's Kennedy Space Center. There might even be webcams in space!

Other applications are:

  1. Commercialization of space for communication services
  2. For mining the asteroids
  3. For the operation of space-based hotels
  4. For manufacturing
  5. For medical treatments
  6. And for general tourism.

First Stop: Mars

Take a look at the the 1997 Mars Pathfinder rover mission and you will understand space explorers need an interplanetary Internet for deep space communications. Data from the Pathfinder trickled back at an average rate of about 300 bits per second during its mission. Most likely, your computer can transfer data at least 200 times faster than that. An Internet between Mars and Earth would likely yield a data transfer rate of 11,000 bits per second. That is still much slower than your computer's transfer rate, but it would be enough to send back more detailed images of the Mars surface. Mars Network researchers think that the transfer rate could eventually go to about 1 Megabyte (8,288,608 bits) per second and allow anyone to take a virtual trip to Mars.


Above Photo is courtesy to NASA / JPL Six micro satellites like this one might be put into low Mars orbit to increase data return from Mars missions.

An interplanetary Internet is like the Earth's Internet on a grand scale and with some improvements. Here are the three basic components of the proposed interplanetary Internet:

  • NASA's Deep Space Network (DSN).
  • A six-satellite constellation around Mars.
  • A new protocol for transferring data.

The NASA Deep Space Network - or DSN - is an international network of antennas that supports interplanetary spacecraft missions and radio and radar astronomy observations for the exploration of the solar system and the universe. The network also supports selected Earth-orbiting missions.

The DSN currently consists of three deep-space communications facilities placed approximately 120 degrees apart around the world: at Goldstone, in California's Mojave Desert; near Madrid, Spain; and near Canberra, Australia.

In an interplanetary Internet, the DSN will be the Earth's gateway or portal to that Internet. In a paper published by the MITRE Corp., a company that is financing the Interplanetary Internet Study, researchers suggest that the DSN's antennas could be pointed at Mars to connect Earth and Mars for at least 12 hours each day. Satellites orbiting Mars should provide a full-time connection between the two planets. A Martian rover, probe or human colony will provide a Mars portal to the interplanetary Internet.

Under the Mars Network plan, the DSN will interact with a constellation of six microsatellites and one large Marsat satellite placed in low Mars orbit. These six microsats are relay satellites for spacecraft on or near the surface of the planet, and they will allow more data to come back from Mars missions. The Marsat will collect data from each of the smaller satellites and beam it to Earth. It will also keep Earth and distant spacecraft connected continuously and allow for high-bandwidth data and video of the planet, according to Mars Network officials. NASA could launch a microsat as early as 2003, with the six-microsat constellation orbiting Mars by 2009. In 2007, the Marsat is scheduled to be placed in a slightly higher orbit than the constellation. All of these dates are still very tentative.


With the increasing pace of space exploration, Earth will distribute large numbers of robotic vehicles, Landers, and possibly even humans, to asteroids and other planets in the coming decades. Possible future missions include lander/rover/orbiter sets, sample return missions, aircraft communicating with orbiters, and outposts of humans or computers remotely operating rovers. All of these missions involve clusters of entities in relatively close proximity communicating with each other in challenging environments. These clusters, in turn, will be in intermittent contact with one another, possibly across interplanetary space. This dual-mode communications environment: relatively cheap round-trips and more constant connectivity when communicating with "local" elements coupled with the very long-delay and intermittent connectivity with non-local elements has led us to the architecture just described.

The Internet has undergone many changes as it has grown from its conception in the 1960's. It began as a robust way for military organizations to have assured computer communications after a nuclear strike. It then evolved into a network used by researchers to share scientific data. It then took on the role of an email messaging service - a role that exploded in the mid-90's with the advent of the Web transforming the Internet into a planetary nervous system we can't imagine living without. If history tells us anything, it's that the Internet will continue to grow and add new capabilities. Wiring up the solar system certainly seems like the next big challenge.

While there is a core team of six people working on this project. The IPN team is looking for more people to get involved in this project either through the IPN special interest group or through post-graduate studies.

About the Author:

No further information.


Prashant Gaur on 2009-03-20 20:35:23 wrote,

A really very gud article..!!!