VISVESVARAYA TECHNOLOGICAL UNIVERSITY

S.D.M COLLEGE OF ENGINEERING AND TECHNOLOGY

A seminar report on

INTERPLANETARY INTERNET

Submitted by

Arunkumar Patil 2SD06CS121 8th semester

DEPARTMENT OF COMPUTER SCIENCE ENGINEERING

2009-10

1 | P a g e

VISVESVARAYA TECHNOLOGICAL UNIVERSITY

S.D.M COLLEGE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE ENGINEERING CERTIFICATE

Certified that the seminar work entitled “Interplanetary Internet” is a bonafide work presented by Arunkumar Patil bearing USN NO 2SD06CS121 in a partial fulfillment for the award of degree of Bachelor of Engineering in Computer Science Engineering of the Visvesvaraya Technological University, Belgaum during the year 2009-10. The seminar report has been approved as it satisfies the academic requirements with respect to seminar work presented for the Bachelor of Engineering Degree.

Staff in charge H.O.D CSE

Name: Arunkumar Patil.

USN:2SD06CS121

2 | P a g e

CONTENTS:

1. INTRODUTION TO IPN. 5

2. WHY IPN? 7

3. TECHONOLOGY CONVERGENCE 8

4. ARCHITECHURE OF IPN 9

5. DELAY TOLERANT NETWORK PROTOCOL.-DTN 11

6. COMPARISION 16

7. IPN SECURITY REQUIRMENTS. 18

8. ADVANTAGES OF IPN. 21

9. LIMITATIONS OF IPN. 21

10. FUTURE USES OF IPN 22

11. CONCLUSION. 23

12. REFERENCES. 23

3 | P a g e

ABSTRACT

A strategy is being developed whereby the current set of internationally standardized space data communications protocols can be incrementally evolved so that a first version of an operational. “Interplanetary Internet” is feasible by the end of the decade. This paper describes its architectural concepts, discusses the current set of standard space data communications capabilities that exist to support Mars exploration and reviews proposed new developments. It is also speculated that these current capabilities can grow to support future scenarios where human intelligence is widely distributed across the solar system and day-to-day communications dialog between planets is routine. 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 inter-process 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.

4 | P a g e

1.INTRODUCTION

The Interplanetary Internet (IPN) is a conceived computer network in space, consisting of a set of network nodes which can communicate with each other.

The vision of future space exploration includes missions to deep space that require communication among planets, moons, satellites, asteroids, robotic spacecrafts, and crewed vehicles. These missions produce significant amount of scientific data to be delivered to the Earth. In addition, these missions require autonomous space data delivery at high data rates, interactivity among the in-space instruments, security of operations, and seamless inter- operability between in space entities. The next step in the design and development of deep space networks is expected to be the Internet of the deep space planetary networks and defined as the Interplanetary (IPN) Internet.

The Interplanetary Internet is envisioned to provide communication services for scientific data delivery and navigation services for the explorer spacecrafts and orbiters of the future deep space missions. All of these future space missions have a common objective of scientific data acquisition and delivery, which are also the main possible applications of the Interplanetary Internet. It became apparent to our team that the space communications research community and the Internet research and development community were pursuing technology paths that can potentially lead to a kind of convergence. A few members of the Internet community began thinking about adaptation of the terrestrial Internet to deep space communications. The space communications research community was already trying out variants of the Internet's TCP/IP protocol suite to support space-based applications. Mutual recognition led to the formation of a program of work that was aimed at extending the notion of Internet to interplanetary scale.

The heretofore-independent "rivers" of evolving space technology and Internet technology are converging in this program. To realize this convergence, the effort to define the IPN architecture is being undertaken at the Jet Propulsion Laboratory (JPL) that is operated by the California

Institute of Technology (Caltech) for the US National Aeronautics and Space Administration

5 | P a g e

(NASA). An Interplanetary Internet Research Group (IPNRG) has been formed under the auspices of the Internet Research Task Force of the Internet Society and an Interplanetary

Internet Special Interest Group has also been created as a means of keeping the public informed as to progress. Early protocol design phases are underway now and prototype of candidate designs is anticipated within a year. The Mars exploration program is particularly interesting as a

"reference model" for our work, since it includes a "Mars Network" project that hopes to deploy a series of remote communications satellites into orbit around the planet. These satellites will be dedicated to servicing the local communication and positioning requirements of the other in-orbit and surface observation and exploration missions that are in the vicinity of the planet. By 2010, as many as seven communications and navigation satellites could be in orbit around Mars, most in low Mars orbit (LMO) but with perhaps at least one in an "aero" synchronous orbit that is analogous to a geosynchronous orbit around the Earth.

6 | P a g e

2.WHY IPN? An immediate application would be to help facilitate communications between Mars and Earth. By happy coincidence, a new study underway at NASA called the Mars Network aims to do exactly this. The Mars Network would consist of a constellation of microsatellites and one or more (larger) Mars Aero-stationary Relay Satellites. This system would be used to support the Mars sample return missions and other surface and orbital activities. By placing this infrastructure in place around Mars individual spacecraft on Mars would not require as much communications capability as is presently the case. This could allow mission designers to either use smaller spacecraft, or devote more weight and volume to scientific payloads.

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 missions to Mars and planets beyond. The interplanetary Internet will possibly wire us to Mars within the decade and to other planets in the decades to follow. It will no longer be necessary to go into space to experience space travel. Instead, space will be brought right to your desktop. If we ever want to find out more about other planets, we will need a better communication system for future space missions. With this kind of network in place, the communications problems resulting from having very little communications infrastructure in place at Mars that plagued the 'rescue' efforts after the Mars Polar Lander disappeared would be greatly simplified.

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 someday 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!

7 | P a g e

3. TECHNOLOGY CONVERGENCE

Team of the space communications research community and the Internet research and development community were pursuing technology paths that can potentially lead to a kind of convergence. A few members of the Internet community began thinking about adaptation of the terrestrial Internet to deep space communications. The space communications research community was already trying out variants of the Internet's TCP/IP protocol suite to support space-based applications. Mutual recognition led to the formation of a program of work that was aimed at extending the notion of Internet to interplanetary scale. The heretofore-independent

"rivers" of evolving space technology and Internet technology are converging in this program.

To realize this convergence, the effort to define the IPN architecture is being undertaken at the

8 | P a g e

Jet Propulsion Laboratory (JPL) that is operated by the California Institute of Technology

(Caltech) for the US National Aeronautics and Space Administration (NASA). An Interplanetary

Internet Research Group (IPNRG) has been formed under the auspices of the Internet Research

Task Force of the Internet Society and an Interplanetary Internet Special Interest Group has also been created as a means of keeping the public informed as to progress.

4. ARCHITECTURE

The future Interplanetary Internet architectural concept is deceptively simple:

Use Internet or Internet-related protocols to form local networks in low delay, relatively low noise environments.

A specialized deep space backbone network of wireless links interconnecting these local internets. This interplanetary backbones is expected to evolve to include multiple space-based data relay satellites.

The resulting interplanetary internet thus consists of a "network of internets". Just as the familiar TCP/IP suites the earth “networks of networks” into the internet, Interplanetary Internet will employ a new overlay protocol concept called bundling to tie together a set of heterogeneous internets. A routing function will direct bundles through a concatenated series of Internets. To guarantee reliability of the end-to-end transfer, the bundles will also contain retransmission mechanisms functionally similar to those provided by the terrestrial Internet’s Transmission Control Protocol(TCP).While the Earth’s backbone network is wired the interplanetary backbone is dependent on fragile wireless links. Planets travel in fixed orbits and sometimes bodies like the Sun cause line of sight occultations that last for days on end. Landed vehicles on remote planetary surfaces will move out of sight of Earth as the body rotates, and may have to communicate through local relay satellites that only provide data transmission contacts for a few minutes at a time. The bundling protocol handles this environment in two ways:

• It operates in a “store and forward” mode, where bundles are held at routers along the way until such time as a forward path is established.

9 | P a g e

• It avoids the need for a sender to store data until an acknowledgement is received from the other end by operating in a "custodial" mode.

• In the presence of high error rate links, the hop-by-hop store-and forward bundling model with per-hop error control increases the probability of successful end to end transmission.

One key in the design of an Interplanetary Internet is identifying the communicating endpoints. 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 gets the bundle delivered to a remote destination “region” of the Inter planetary internet. The second part of the name 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.

10 | P a g e

 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.

5. DELAY TOLERANT NETWORK PROTOCOL.-DTN

A new networking technology called DelayTolerant Networking (DTN) could give astronauts direct Internet access within a year. The technology currently is being tested aboard the International Space Station (ISS), and could lead towards what has been dubbed the "Interplanetary Internet".DTN communications protocol is a like TCP/IP, which defines how information is encoded and routed through a network.

However, while TCP/IP deals with a continuous end-to-end network of Internet hosts and computers,

DTN deals with spacecraft whose communications may be disrupted as they travel.DTN deals with

11 | P a g e disruptions by storing unsent data packets in a queue until conditions allow for them to be transmitted.The so-called "store-and-forward" method could withstand disruptions of seconds, hours or even days, a researcher at the University of Colorado at Boulder who is working with NASA to develop

DTN.Compared to the manually scheduled, point-to-point links that are currently used for communications between ground stations and spacecraft, DTN could lower costs and enable new, more complex space missions. Depending on the physical wireless networking layer on which DTN operates, an Interplanetary Internet could transmit information at the speed of light, across "millions of miles" The researchers launched a DTN-enabled payload to the International Space Station (ISS), which is to be the first permanent node of the Interplanetary Internet.

By late 2010, DTN could enable astronauts truly to Twitter from space.

DTN could also be applied on Earth, to improve wireless Internet on aircraft, third world connectivity or for wildlife tracking, he noted, adding that the researchers do not have commercialisation plans.

The researchers are currently in discussions with the European Space Agency and the Japan Aerospace Exploration Agency to install DTN on their respective ISS modules in mid- 2010.

In the IPN, we cannot ever assume that there is direct connectivity between source and destination. That is, we cannot assume that bits emitted by a source can travel, delayed only by routing and transmission delays, to the destination. There may be any number of reasons for this, ranging from physical (the destination is on the far side of a distant planet and can't communicate with anything right now), to schedule-related (a required IPN gateway is currently serving other customers), to administrative (the source is only on during the day, the destination only during the night). For the long-haul links of the backbone, information will almost certainly have to be stored for some amount of time as the antennas used for the long-haul links will almost surely be

12 | P a g e highly directional. 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. 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. It should be noted that terminating the transport protocols at the IPN nodes decouples the internets in different IPN regions to a significant degree. This has the desirable effect of also decoupling the evolutionary rates of those internets: changes in the

13 | P a g e

Earth's Internet do not necessarily dictate changes in other internets. This is important in an environment in which resources are and will continue to be severely constrained. 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."

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. If the source desires notification of delivery, that is accomplished by a separate return receipt, which is transmitted as its own bundle, and is subject to the same custody transfers as the original transmission (similar to the fact that a postal return receipt is, in itself, a postcard). It is shown figuratively as bypassing the forwarding path (E to D to C to B to A), but this is simply for clarity. The return receipt is forwarded in exactly the same manner as the original data is.

14 | P a g e

Delay/Disruption-Tolerant Networking follow the “STORE and forward” approach to bundle transmission. That is, once the bundle is generated at the source, it is transferred on a hop-by-hop basis until it reaches its destination. However, once a node accepts the custody transfer of an incoming bundle, it has to receive the whole bundle before it can forward it to the next node. Although this approach seems to be suitable for long-delay, intermittently connected links, it may also become an obstacle to fast end-to-end bundle transmission, from a resource-availability perspective. That is, provided that connectivity is sparse and intermittent, a node should exploit all available transmission opportunities. In that context, if the link to the next node is operational, then “store and FORWARD” may comprise a more elegant approach to bundle delivery. In other words, the receiving node stores the incoming bundle, but it may also begin transmission of the bundle-fragment that has already arrived, to the next hop, if this is feasible.

Moreover, DTNs may consist of relatively short-propagation delay regions, such as planetary networks. In this case, alternative paths may serve the bundle transmission process if the original link fails. In contrast, current practice (i.e., “STORE and forward”) does not allow for bundle-fragmentation /re-fragmentation and autonomous routing on the fly. The “store and FORWARD” functionality, however, may require modifications to the Bundle Protocol.

Routing functionality may either be implemented below the Bundle Layer or alternatively the Bundle Protocol will need operational and structural modifications. In particular,

• the bundle layer will need to fragment bundles into smaller packets/segments according to the path Maximum Transmission Unit (MTU), and

• the bundle header will need to be included in all packets/segments produced by the bundle layer.

Otherwise, individual packets will not include enough information in order to be dynamically and autonomously routed to the destination. Unfortunately, such an approach will increase the Bundle Protocol's byte-overhead. In essence, the bundle layer provides a common method for interconnecting heterogeneous gateways, and overcomes communication disruptions by

15 | P a g e employing store-and-forward message switching based on non-volatile storage. DTN introduces another layer of abstraction offering applications an interface to cross over a number of differing networking environments. Also, the custody transfer capability facilitates data trasports exploiting in-network storage. Nevertheless, it is neither obvious nor assured that DTN offers better performance throughput-wise, compared to other alternatives. However, implementing DTN requires adding relevant components to the target network infrastructures and induces overhead, which has to be quantified on the basis of experiments and simulations.

Finally, we note that DTN does not eliminate the need for a space agency to cross- support others, so that they can share their facilities. DTN is layer-agnostic and thus requires an appropriate convergence layer, in accordance with the underlying protocol stack. Should the offered services by the lower-level layers not provide the desired functionality for DTN applications, the convergence layer should implement the missing functionality. Also, the bundle protocol introduces byte-overhead which is appended to the application data units during bundles construction.

6. COMPARISION OF IP AND DTN:

One research direction for interoperable space communications favors deploying the Internet Protocol (IP) in order to interconnect space-based networking entities among themselves, and with the ground systems. In the simplest case, a single IP address can be assigned to a spacecraft, thus affecting only the interface from the Command and Data Handling system to the space link. A more advanced implementation is to configure distinct IP addresses for various subsystems and devices on-board the spacecraft. In either case, IP's global addressing can provide a common addressing scheme, which can be considered as the first step towards interoperable communications. If a modified IP could solve the routing and storage problem, and given that the naming/addressing scheme would have naturally found a global solution, the only remaining issue for DTN is the custody transfer and the delay-tolerant transmission policies that needed to support space applications. That is, a single protocol such as LTP-T[12] or DTTP[10], for example, could provide the component missing from the spectrum of desired DTN functions.

16 | P a g e

Note that such an approach is architecturally more elegant; the routing is managed at the network layer and is not unnecessarily hierarchical; the transport relies on routing below and therefore allows for flexible paths between the sender and the receiver; unlike a two-tier routing policy that allows for flexible routes only within the regions. Hence, the decision to reach a new architecture may require further justification.

Nevertheless, there exists a number of challenging problems regarding IP adaptation for space environments. IP may be considered as a delay-tolerant protocol since its forwarding functionality is not inherently constrained by time; its association with time constraints comes only as a side-effect of the limited buffering capacity.

Both IP and the Bundle protocol encompass routing tasks, which present increased complexity in intermittently connected networks with excessive propagation delays and moving network nodes. Thus, each approach will eventually have to devise equivalent methods for construction of routing tables, though from a different perspective. Bundle protocol hides the underlying protocol stacks upon which it operates, and requires routing information that connects bundle-nodes at the application layer. That does not preclude routing protocols at a lower layer. Instead, routing can actually occur at two levels: inside each autonomous system (assuming a set of heterogeneous networks), and also between the higher-level bundle-nodes. IP, on the other hand, lays a common addressing scheme that can seemlessly integrate differing networks. We consider that implementing delay-tolerant behavior for IP routers in space, is essentially a feasible task. Assuming a lower layer or connection management engine responsible for ceasing/resuming transmission, IP packets (like in the case of bundles) can certainly be stored in permanent storage, waiting for the connection to a destination peer to become available.

Given the prior knowledge pertaining to the relevant movement of space objects - and ground-based network nodes, a more-or-less static routing system is expected to govern space internetworking. At least, ground stations (either on Earth, Moon, Mars, or elsewhere), and relay satellites with predetermined orbits, offer a deterministic routing framework that can serve as the backbone for space data communications. That said, the appropriate layer for deployment of the routing functionality may be different for scheduled and opportunistic or random contacts and correspond to the requirement for flexible or predetermined paths2, respectively. In case of scheduled contacts, the routing functionality may be implemented at the higher layers, since the

17 | P a g e bundle route is known and predetermined. In contrast, opportunistic contacts need to rely upon a flexible routing scheme below the Bundle layer in order to be able to alter between various alternative paths. That is, once a bundle is generated, it either needs to know its route to the destination from the beginning (i.e., scheduled contact) in order for the bundle layer to route it accordingly, or the unknown destination has to be determined on the fly by lower layers. Alternatively, the Bundle Protocol will need to be modified in order to fragment bundles into smaller data units and include routing information in each fragment. By the same token, the routing policy will very much determine whether the “STORE and forward” or the “store and FORWARD” transmission policy will be adopted.

7. 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. There are two aspects to IPN security: protection of the IPN infrastructure and protection of the data traversing the IPN. The protection of the IPN infrastructure is not unlike the protection required for the Earth-based Internet infrastructure. There will be a need to exchange routing information securely among the IPN nodes as well as to securely manage them. For the IPN infrastructure to protect itself, the IPN nodes need to be mutually suspicious of one another. That is, the IPN nodes will authenticate themselves to each other to ensure that they are not being spoofed by an untrustworthy entity. One might ask if this is overkill if we believe that there will always be a small, controlled number of IPN nodes (a la the original ARPANET). However, one could equally envision that there could be many IPN nodes that are sponsored and controlled by

18 | P a g e multiple organizations (a la the current Internet). Since we would like the IPN to easily scale, we want to build mutual suspicion and security mechanisms into the IPN architecture from the outset. It should be noted that the same mechanisms could be used to provide security for both the IPN infrastructure and the data flowing through it.

Assumptions Regarding Required IPN Security Mechanisms

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

* Access control

* Authentication

* Data integrity

* Data privacy

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).

User authentication is a capability to prove that the bundle has been sent by the entity that claims to have sent it.

Typically, an Authentication service ensures that the content of the bundle is unaltered as a means to prevent replay attacks. Authentication is accomplished in a public key system by the use of a digital signature. A digital signature is created by computing a hash of the data to be covered by the authentication, and then encrypting that information with the private key of the

19 | P a g e sender. If the sender’s public/private key pair is uncompromised and the cryptographic algorithm is sufficiently strong, the recipient can apply the purported sender's public key to the encrypted data, recover the hash, and compare it to a hash of the corresponding information in the bundle. This allows the recipient to determine if the sender's key is correct (authenticating the sender's identity), and if the data received is identical to the data that was sent (verifying the integrity of the data) hence could be made available to end-users to authenticate them to the remote bundle entity at relatively low cost. However, the remote bundle entity will have to request a trusted copy of the purported sender's public key, potentially adding considerable delay to the receipt of the first bundles until a signed copy of the sources public key is received, verified, and cached.

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 :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.

20 | P a g e

8. Advantages of IPN:

Interplanetary Internet that extends the paradigm of the Earth’s Internet to the solar system. Breakthrough increases in communications IP-like protocols, tailored to operate over the bandwidth and connectivity long round-trip light times of interplanetary links a layered architecture to support resolvability and interoperability seamless end-to-end information flow between science and exploration assets around the solar system and researchers and the public here on Earth integration of navigation functionality to extract position information from the communications links. The Interplanetary Internet is designed to be more robust, so as to cope with the huge latencies of space communication and the long interruptions which occur during solar storms or when a spacecraft moves behind a planet.

"Interplanetary Internet's" ultimate focus is shuttling information throughout the solar system, the implications here on Earth for using its new class of network, the Delay Tolerant Network (DTN), could mean improved communications for the military and for emergency crews.

 Better communication system for future space missions.

 An interplanetary Internet that will connect us to human space travelers.

 Allow more information to be sent back to Earth.

9.LIMITATIONS OF IPN:

As you move farther out into space, there is a delay of minutes or hours. When interplanetary distances are involved - and the distance signals need to travel is measured in light minutes - or hours, interactive protocols just don't work. To solve this problem a "store and forward" methodology will be used. The user's request for information will be sent to a gateway, processed, and forwarded to its final destination. Once at its destination, the request will be checked, queued, and then processed and forwarded back down the path it came.

The possibility of hacker break-ins.

21 | P a g e

10.FUTURE USES OF IPN.

The potential applications of a Inter-Planetary 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! significant increase in the use of mobile, wireless internet nodes.

There are a lot of potential applications. One of the simplest is "Mars TV." Imagine that you set down a rover with multispectral imagers and cameras and that bandwidth was no object. You could just start sending back a stream of video from the surface of the planet and provide Mars TV. Businesses could also use the streaming video to develop entertainment applications. They could build a software model of the martian environment and combine it with visual and tactile sensors to allow anyone to be a virtual astronaut. You could basically step into this virtual martian environment and explore it yourself.

Some of the Application where we can make use of this technology to work more effectively can be in some of the areas: These same cores could be adapted to earth for delay dependent networks (e.g., sensor networks with intermittent links, mobile medical networks).

• Delay Dependent Networks

• Sensor Networks

• Military Tactical Networks

• National Emergency Communication Infrastructure

• 24/7 Health Monitoring of Remotely Located Patients

• Mobile Medical Networks

22 | P a g e

11.CONCLUSION

A rich and proven set of international standards are already existing to support our needs for communicating between Mars and Earth. Those standards will continue to evolve and grow in capability. Many researchers and several international research organizations are currently engaged in developing the required technologies to realize the Interplanetary Internet. Despite the considerable amount of ongoing research in this direction, there still remains significantly challenging tasks for the research community to address before the realization of the interplanetary Internet. 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, with the following working conclusions.

12.REFERENCES:

www.ipnsig.org

www.ingentaconnect.com.

http://www.ipnsig.org

http://www.planetary.org

http://deepspace.jpl.nasa.gov

http://www.spaceref.com

23 | P a g e