Expounding the Intricacies and
Recent Developments in Interplanetary Internet
Jivesh Govil
Digital Signal Processing Laboratory Electronics and Communication Division
Netaji Subhas Institute of Technology, University of Delhi Dwarka, New Delhi, India 110075
Abstract- Interplanetary (IPN) Internet is expected to be the next step in the design and development of deep space networks as the Internet in the space. The IPN 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 [1]. 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. In this article we present a survey of the proposed architectures and communication protocols and algorithms for deep space networks and Interplanetary Internet. However, there are significant challenges to be addressed for the realization of this objective. This article captures the current state of the art and open research challenges, and intends to motivate researchers around the world to tackle these challenging problems and help realize the IPN Internet.
I. INTRODUCTION
Developments in the space technologies are enabling the realization of deep space scientific missions such as Mars exploration. Future orbiting sensor constellations will consist of tens, hundreds, or even thousands of spacecraft, each capable of generating enormous amounts of data. Managing these constellations will require that the spacecraft be autonomous, deciding without human intervention what observations to make and asynchronously reporting results. The need for a robust and efficient shared network infrastructure combined with the desire to provide direct connectivity between orbiting instruments and scientists on the Internet argues for connecting these sensor constellations directly to the Internet. For successful transfer of scientific data and reliable navigational communications, NASA enterprises have outlined significant challenges for development of next generation space network architectures. The next step in the design and development of deep space networks is expected to be the Internet of the space planetary networks and defined as the Interplanetary (IPN) Internet [2]. Fig. 1 shows the IPN Internet first envisioned by Burleigh and Cerf [3].
The future Interplanetary Internet architectural concept has simple basics:
1. Use Internet or Internet-related protocols to form local networks in low delay, relatively low noise environments such as around Earth, within a free flying spacecraft, on and around another planet, etc.
2. A specialized deep space backbone network of long-haul wireless links interconnecting these local internets.
This interplanetary backbone is expected to evolve to include multiple space-based data relay satellites.
3. The resulting interplanetary internet thus consists of a "network of internets". Just as the familiar TCP/IP suite unites the Earth's "network of networks" into the Internet, the Interplanetary Internet will employ a new overlay protocol concept called bundling to tie together a set of heterogeneous internets.
However, there are significant challenges posed by the deep space networking paradigm that need to he addressed for this objective:
1.Extremely long and variable propagation delays 2.Asymmetrical forward and reverse link capacities 3.High link error rates for radio frequency
4.Intermittent link connectivity
5.Effects of planetary distances on the signal strength and protocol design
6.Power, mass, size, and cost constraints for communication hardware and protocol design
7.Backward compatibility requirement due to high costs involved in the deployment and launching processes Many researchers and several international research organizations are currently engaged in addressing these challenges and developing the required technologies for realization of IPN Internet.
Figure 1. Interplanetary Internet in 2020 as envisioned by Burleigh and Cerf at IPNRG Seminar, Arlington VA, March 2000. II. INTERPLANETARY(IPN)INTERNET ARCHITECTURE
To build a general space Internet architecture that combines differently -challenging parts, Akyildiz proposed the modern view of the Interplanetary Internet is depicted in Fig. 2. It includes Interplanetary Backbone Network, Interplanetary External Networks, and Planetary Networks [4].
Figure 2. Modern view of Interplanetary Internet architecture by Akyildiz
Interplanetary Backbone Network: It provides a common infrastructure for communications among the Earth, outer-space planets, moons, satellite, and relay stations placed at gravitationally stable Lagrangian points of planets, etc. It includes the data links (direct link or multi-hop paths) between elements with long-haul capabilities.
Interplanetary External Network: It consists of spacecrafts flying in groups in deep space between planets, clusters of sensor nodes, and groups of space stations, etc. Some nodes in the Interplanetary External Network also have long-haul communication capabilities.
Planetary Network: The Planetary Network is composed of Planetary Satellite Network and Planetary Surface Network. This architecture can be implemented at any outer-space planet, providing interconnection and cooperation among the satellites and surface elements on a planet. Fig. 3 shows the expanded view of planetary network architecture.
Figure 3. The Planetary Network architecture.
1. Planetary Satellite Network: It is composed of satellites which lie in multiple layers and provides the following services: Intermediary caching and relay service between the Earth and the planet, relay service between the in-situ mission elements, and location management of Planetary Surface Networks.
2. Planetary Surface Network: It provides the communication links between high power surface elements, such as Rovers and Landers, which have the capability to connect with satellites. They also provide a power-stable wireless backbone in the planet. Moreover, Planetary Surface Network includes surface elements that cannot communicate with satellites directly. These elements are often organized in clusters and spread out in an ad-hoc manner, e.g., sensor nodes and balloons as illustrated in Figure 3.
III. IPNINTERNET WORKING
A. Problem with Internet Protocols
The Internet protocols are in general poorly suited to operation on paths in which some of the links operate intermittently or over extremely long propagation delays. The principal problem is reliable transport, but the operations of the Internet’s routing protocols would also raise troubling issues.
Excessive latency affects TCP directly by severely limiting its throughput performance or interfering with connection establishments [5]. Any application-layer protocol using TCP as its underlying transport is therefore affected (BGP and DNS zone transfers). Excessive latency also adversely affects the proper operation of conventional routing protocols as links will be incorrectly discovered to be non-operating when soft-state refreshes are delayed too long (RIP), or a lack of response to link state “hello” messages (OSPF, EIGRP) is observed.
Data rate asymmetry adversely affects TCP by altering the smooth flow of acknowledgments. Studies have indicated that bandwidth asymmetry can lead to poor performance of unidirectional transfers due to alterations in the time series of the ACK channel [6]. Any application layer protocols attempting to use TCP over asymmetric links are therefore affected as well.
Significant path loss affects the TCP transport most strongly, causing it a number of problems. After multiple loss events it will continue retrying with a backed-off retransmission timer until it gives up on retransmitting altogether and closes the connection. IP provides no mechanism for fragment retransmission, thereby causing the overall probability of successful datagram delivery to be further reduced if datagrams are fragmented.
Node longevity affects the probability of end-to-end delivery, as round-trip or even one-way delivery time of a particular message may exceed the sender’s lifetime. Clearly, in such cases it is useless to arrange for immediate acknowledgements to be returned.
B. Current CCDS Space/Ground Protocol Stack
The current space/ground protocol stack is proposed by the CCSDS for space communications [7]. A specific implementation of the stack is shown in Fig. 4. It is used for Mars Exploration mission communications [7], and its functionalities are mapped to the generic eight layers of the current space/ground protocol stack as follows: 1.Space Wireless Frequency and Modulation: Providing
efficient modulation with specified frequencies to create channels between spacecrafts. The frequency and modulation techniques are different for different parts of the Interplanetary Internet. For example, Earth may use local terrestrial wired while the deep space backbone uses CCSDS S, X, or Ka Band as shown in Fig. 4. For Mars orbit and Mars surface, the physical links are also different.
2.Space Channel Coding: Detecting/correcting errors in a noisy channel for reliable data transfer. The channel coding used for Mars orbit and surface is different than at Earth because of the noise level differences.
Science Balloons
Trunk Line to Earth
Rover Probes Base StationLanders/ Science
Orbiter
End-to-End Applications (e.g., Bundle FTP, CFDP, Bundle NTP)
Bundle API B undl e Ro ut in g B u n d le C u st od y T ra n sf er B u n d le e n d -t o -e n d re lia b ilit y B u n d le A p p lic a tio n Bu n d le E n cr yp tio n B u n d le T B D S er vic e s
Convergence Layer (specific adapters that map Bundles to underlying transmission services) Licklider Transmission Protocol
(LTP)
IP
TCP UDP
CCSDS
Long-haul link Proximity linkCCSDS SONET Ethernet End-to-End Applications
(e.g., Bundle FTP, CFDP, Bundle NTP) Bundle API B undl e Ro ut in g B u n d le C u st od y T ra n sf er B u n d le e n d -t o -e n d re lia b ilit y B u n d le A p p lic a tio n Bu n d le E n cr yp tio n B u n d le T B D S er vic e s
Convergence Layer (specific adapters that map Bundles to underlying transmission services) Licklider Transmission Protocol
(LTP)
IP
TCP UDP
CCSDS
Long-haul link Proximity linkCCSDS SONET Ethernet
Figure 4. The Mars communication protocol stack
3.Space Link: Providing retransmission capability in deep space environment. Often times, data are transmitted through a very long distance. Because of this, different protocols other than the ones at Earth are needed to address this issue. For instance, the CCSDS long-haul link and coding protocol is used as illustrated in Fig. 4. 4.Space Networking: Providing connection oriented path
for CCSDS Packet used by the Packet Telemetry and Telecommand.
5.Space End-to-end Security: Providing protection against attacks on the flow of user data. Two of such security protocols are Internet Protocol Security (IPSec) and SCPS Security Protocol (SP). The IPSec is used in the Earth side, while other deep space end-to-end security protocols are required as shown in Fig. 3.
6.Space End-to-end Reliability: Ensuring packets in a session are arrived at the destination. For short delay communications, the CCSDS recommends TCP and TCP Tranquility, which is an extension of TCP. For non-connection oriented services, the UDP may be used. The TCP is used in Earth while TCP Tranquility is used in Mars orbit and surface.
7.Space File Transfer: Transferring independent files that can be assigned priority in downloading. Two current CCSDS file transferring protocols are FTP and SCPS extensions to FTP for short delay connection and CCSDS File Delivery Protocol (CFDP) for long delay link. The CFDP is used by all the components of the Interplanetary Internet as shown in Fig. 4.
8.Space Applications
C. Delay Tolerant Architecture
It is this analysis (problem with Internet Protocols) that lead to the proposal of an architecture based on Internet-independent middleware: use exactly those protocols at all layers that are best suited to operation within each environment, but insert a new overlay network protocol between the applications and the locally optimized stacks. The overlay protocol serves to bridge between different stacks at the boundaries between environments in a standard manner, in effect providing a general-purpose
application-level gateway infrastructure that can be used by any number of applications.
A routing function will direct bundles (messages) through a concatenated series of Internets, conceptually just as the Earth’s Internet protocol (IP) routes data through a series of independent networks on Earth. To guarantee reliability of the end-to end transfer, the bundles will also contain retransmission mechanisms functionally analogous to those provided by the terrestrial Internet’s Transmission Control Protocol (TCP).
The bundling protocol handles the space environment in two ways:
1.It operates in a “store and forward” mode, very similar to e-mail, where bundles are held at routers along the way until such time as a forward path is established. 2.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 this mode, intermediate nodes in the network can assume responsibility for ensuring that bundles reach their destinations, allowing senders (and previous custodians) to reassign resources to new observations.
The CCSDS File Delivery (CFDP) is- by design- a prototypical form of the bundling protocol. The current CFDP consists of three parts: File handling mechanisms; Point-to-Point reliability mechanisms, which draw upon underlying; and Space link data transfer services.
The current bundling protocol architecture (Fig. 5) improves on CFDP in several key respects:
Figure 5. Current bundling Architecture
1.It is not confined to supporting just file transfer, but it can handle virtually any end-to-end space application. Eventually, CFDP will simply “move up the stack” to become one of those applications.
2.Its internal functions are more clearly modular than CFDP, so that it should be easier to evolve over time. 3.It will provide a more flexible custodial transfer
capability than is achievable with CFDP.
Extensions to CFDP are presently under development that will allow it to support multihop file data transfers of
Internet Earth
InterPlaNetary Internet Backbone Network Deep Space Backbone
PlaNetary Satellite Network
PlaNetary Surface Network Mars Orbit Mars Surface CCSDS File Delivery Protocol
CCSDS TCP Tranquility CCSDS End-to-End Security CCSDS Path, Network or IP CCSDS Long-Haul Link and Coding
CCSDS Proximity Link and Coding CCSDS Link Security
CCSDS
S, X or Ka Band CCSDS UHF
CCSDS UHF (or local wired/
wireless) Local Terrestrial Wired Local Terrestrial Link TCP,UDP IPSEC IP Internet Earth InterPlaNetary Internet Backbone Network Deep Space Backbone
PlaNetary Satellite Network
PlaNetary Surface Network Mars Orbit Mars Surface CCSDS File Delivery Protocol
CCSDS TCP Tranquility CCSDS End-to-End Security CCSDS Path, Network or IP CCSDS Long-Haul Link and Coding
CCSDS Proximity Link and Coding CCSDS Link Security
CCSDS
S, X or Ka Band CCSDS UHF
CCSDS UHF (or local wired/
wireless) Local Terrestrial Wired Local Terrestrial Link TCP,UDP IPSEC IP
the sort envisioned by the “Mars Network” concept, where multiple Mars orbiters provide data relay services in the vicinity of the planet.
IV. OTHER RECENT ASPECTS TO IPNINTERNET
A. Security Issues
Terrestrial Internet security has been moving forward on three fronts: IP layer security (IPSEC), Secure Sockets Layer (SSL)/Transport Layer Security (TLS), and secure electronic mail using S/MIME or PGP. These security mechanisms, while operating at different layers of the Internet protocol suite, provide security service such as confidentiality, integrity, authentication, and non-repudiation. The Interplanetary Internet also requires security services to provide protection.
However, the IPN differs from the terrestrial Internet in that there is little bandwidth available and connectivity is not always guaranteed between IPN entities. To implement the security model, each message includes an immutable “postage stamp” (a type of capability) containing a verifiable identity of the sender (or role), an approval (and approving authority) of the requested class of service (CoS) associated with the message, and other conventional cryptographic material to verify accuracy of the message content. Routers check credentials at each DTN hop, and discard traffic as early as possible if authentication fails. This approach has the associated benefit of making denial-of- service attacks considerably harder to mount as compared with conventional Internet routers.
B. Need for Time Synchronization
The DTN architecture requires a coarse level of time synchronization, which is used for identifying message fragments [8] and also for purging messages that have exceeded their source-specified lifetimes. The motivation stems from the observation that synchronized timing is needed by many distributed applications used in challenged environments and is required by the DTN’s approach to scheduling and path selection. In addition, given reasonably accurate time synchronization, DTN congestion management techniques can conceivably predict at what times congestion may abate. Protocols such as NTP [9] have provided 1ms accurate time synchronization (or better) within the Internet for years, and most existing networks for extreme environments already provide some (often out-of-band) means for obtaining accurate time.
V. NEW PROTOCOLS FOR IPNINTERNET
Recently, new transport and routing protocols have been proposed keeping in mind the various challenges faced by Interplanetary Internet as listed in the introduction.
A. Transport Protocol for IPN Internet
Among the various challenges to IPN Internet, very long propagation delay time has a significant effect on the traditional TCP protocols for reliable traffic and the rate control schemes for real-time multimedia traffic.
The way the Round Trip Time (RTT) value affects the performance of traditional TCP protocols can be justified
by two facts: the start phase interval, i.e., the time for TCP to reach a given window threshold, is dependent on the RTT value and TCP throughput is also dependent on the RTT value. If the RTT value is very large, the throughput becomes approximately zero.
For the existing rate control schemes, the initial stage is also a problem because during the initial stage, no network information is available. If the RTT value is very large, how to decide on an appropriate initial data rate is a very challenging problem. Furthermore, most proposed rate control schemes are designed to behave TCP friendly, i.e., their throughput should not exceed those of their TCP counterparts. For example, equation-based rate control schemes use TCP throughput as a reference for rate adjustment. When the RTT value is very large in the case of Interplanetary Internet, the corresponding throughput becomes very low.
As a result, current existing TCP protocols and rate control schemes perform very poor over Interplanetary Internet. Consequently, it is necessary to develop new transport protocols for Interplanetary Internet. Currently, new transport protocols consist of the following two parts: 1.TP-Planet: TP-Planet, aims to achieve high throughput
performance and perform reliable data transmission on space links [10]. TP-Planet is an end-to-end connection-oriented reliable transport protocol specifically tuned to deep space communication requirements. TP-Planet deploys an additive-increase multiplicative-decrease (AIMD) rate-based congestion control protocol. It runs on top of Internet Protocol (IP) layer and does not require any specific modification to the underlying protocols in the current TCP/IP protocol suite.
2.RCP-Planet: RCP-Planet is a real-time traffic transport protocol in Interplanetary Internet and it is mainly run at the sender and requires some functionality at the receiver [11]. RCP-Planet is not an ARQ scheme and hence no retransmission is performed for any missing packet. RCP-Planet runs on top of RTP/RTCP and UDP. The rate control mechanism is not based on ACK reception for the transmitted packet. Therefore, the receiver does not send acknowledgement back to the sender for the data packets it receives. This also helps to save the scarce reverse channel resources which are desirable in Interplanetary asymmetric communication links.
B. Routing Protocol for IPN Internet
To provide inter-operability between different elements in the architecture that may use IP, sensor, or proprietary addressing formats, a universal addressing scheme is needed to locate the elements in the Interplanetary Internet architecture. To support end-to-end communication, the expected new universal addressing scheme should perform the following functions:
1.Locate the elements in a hierarchical way in the Interplanetary Internet architecture, support for efficient routing through different sub-networks and under node movement.
2.Allow the Interplanetary Internet to expand while maintaining the addressability of previously-deployed elements.
3.Dynamically allocate addresses, i.e., retrieve addresses from nodes under power failure or physical damage, and assign new addresses to newly deployed elements A new routing framework, called Space Backbone Routing (SBR), has been proposed by Chen and Akyildiz for routing through different autonomous regions (ARs) in the Interplanetary Internet [12], as shown in Fig. 6. SBR has two integral parts: external (e) and SBR-interior (SBR-i). SBR-e addresses the delivery of remote control message and scientific data through ARs in the IPN Internet. Location-Predicted Directional Broadcast (LPDB) was proposed for reliable delivery of remote control messages and automatic data delivery. In LPDB, paths are calculated en route based on the predictable AR locations. These paths are used to direct and limit the control message broadcast. For controlled data delivery, Receiver-Initiated On-demand Routing (RIOR) is proposed. In RIOR, the route discovery is initiated on-demand by the receiver and routing tables are maintained in soft state at the intermediate AR nodes. SBR-i exchanges inter-AR routing information among backbone nodes within an AR and schedule the inter-AR message transmission. Two important functionalities of SBR-i are contact allocation and traffic dispatching [12]. As a first attempt, the Longest Queues (LQ) policy was proposed for contact allocation for AR border routers and the Minimum Waiting (MW) policy was introduced for scheduling inter-region messages through an AR.
Figure 6. Routing framework of SBR VI. IPNINTERNET APPLICATIONS
Most of future space missions have a common objective of scientific data acquisition and delivery, which are also the main possible applications of the IPN Internet:
1.Time-Insensitive scientific data delivery: The main objective of the IPN Internet is to realize communication between in-space entities allowing large volumes of scientific data to be collected from planets and moons.
2.Time-sensitive scientific data delivery: This type of application is required to deliver great volumes of audio and visual information about the local environment to the Earth, in situ controlling robots, and eventually in situ astronauts
3.Mission status telemetry: The status and health report of the mission, spacecraft, or landed vehicles could he delivered to the mission center or other nodes. This application requires periodic or event-driven unreliable transmission services.
4.Command and control of in situ elements: The closed-loop command and control may involve indirect or multihop communication of remote nodes or close proximity nodes.
VII.CONCLUSION
The vision of future space exploration involves the design and development of next-generation deep space networks, which are expected to be the Internet of the deep space planetary networks and defined as the IPN Internet. In this article, current status of research efforts has been presented and we aim to inspire the researchers to work towards the development of IPN.
REFERENCES
[1] V. Cerf et al., InterPlaNetary Internet (IPN): Architectural defin-ition, Internet draft, draft-irtf-ipnrg-arch-00.txt, May 2001. [2] K. Bhasin, J. Hayden, J.R. Agre, L.P. Clare, T.Y. Yan, Advanced
Comm. .and Networking Technologies for Mars exploration, in: 19th Annual AIAA International Communications Satellite Systems Conference, Toulouse, France, April 2001.
[3] V. Burleigh, V. Cerf, B. Durst, A. Hooke, K. Scott, E. Travis, H. Weiss, Interplanetary Internet, Internet Research Task Force (IRTF): Interplanetary Internet Research Group (IPNRG) Seminar NSF Arlington VA, 01 March 2000
[4] Ian F. Akyildiz, Ozgur B. Akan, Chao Chen, Jian Fang, and W. Su, "State-of-the-Art in Interplanetary Internet," IEEE Communications Magazine, Vol. 42, No. 7, pp. 108-118, July 2004.
[5] R. Durst, G. Miller, E. Travis, "TCP Extensions for Space Communications", Wireless Networks 3(5):389-403, 1997. [6] U. Madhow, T. V. Lakshman, B. Suter, "TCP/IP Performance with
Random Loss and Bidirectional Congestion", IEEE/ACM Transactions on Networking, 8(5), Oct 2000.
[7] S. Burleigh, V. Cerf, R. Durst, K. Fall, A. Hooke, K. Scott, H. Weiss, The Interplanetary Internet: a communications infrastructure for Mars exploration, in: 53rd International Astronautical Congress, The World Space Congress, Houston, Texas, October 2002.
[8] K. Fall, “A Delay-Tolerant Network Architecture for Challenged Internets”, Intel Research Technical. Report IRB-TR-03-003, Feb 2003
[9] D. Mills, “Network Time Protocol (Version 3) Specification, Implementation and Analysis”, Internet RFC1305, Mar 1992 [10] Akan, O.B.; Jian Fang; Akyildiz, I.F., “TP-planet: a reliable
transport protocol for Interplanetary Internet”, IEEE Journal on Selected Areas in Communications, Volume 22, Issue 2, pp. 348-361, Feb. 2004
[12] Ian. F. Akyildiz "RCP-Planet: A Rate Control Protocol for Multimedia Traffic in the InterPlaNetary Internet," Space Internet Workshop 2003 (SIWIII), Cleveland, Ohio, June 4-6, 2003
Space Backbone Routing (SBR)
SBR-exterior
SBR-interior
Remotre Control & Automatic Data
Delivery
Controlled Data
Delivery AllocationContact
Traffic Dispatching Location-Predicted Directional Broadcast(LPDB) Receiver-Initiated On-demand Routing (RIOR) Longest Queues (LQ) Minimum Waiting (MW)
