As humanity’s reach in space exploration extends beyond Earth’s orbit, the demand for robust and efficient communication systems intensifies. The traditional paradigm of isolated missions has given way to a complex network of diverse spacecraft engaged in terrestrial research, lunar exploration, and the provision of essential satellite services. Yet, the limitations of current spacecraft communication technology, which predominantly rely on individual spacecraft connections, are becoming increasingly apparent. These systems grapple with issues of scalability, collaboration, automation, and reliability. This paper addresses these challenges by exploring the development of more sophisticated systems designed to meet the evolving demands of space exploration. It delves into the specifics of the Interplanetary Overlay Network (ION) implementation of Delay and Disruption Tolerant Networking (DTN), a comprehensive software system that accommodates a variety of applications, protocols, and Convergence Layer Adapters (CLAs). The paper also forecasts the future of DTN implementation, highlighting key developments and advancements anticipated between 2023 and 2029. These advancements are expected to enhance the functionality and reliability of DTN-based systems.

An early paper in network interconnection outlined the choices between adoption and adaption of protocol structures at different levels of the early Internet. This paper revisits that theme in the light of the many advances of the last three decades, and the emergence of the Internet of Things. We maintain that there are close parallels between the variety of incompatible networks which were in vogue in the early days of the Internet and the current situation with domain-specific sensor and actuator systems in the Internet of Things. We point out that there is now much more agreement on the approach to basic services, and a more universal approach to adaption. While universal adoption of common technologies is still far distant, there has been a broad consensus on the use of the Internet and web services for the access to such systems. Because of the standardization in some of the levels of web services, particularly in the context of IPv6, a consistent architecture is defined and examples of possible implementations given.

It is becoming increasingly apparent that geographically indexed information has value. Associating information of all kinds with geographic location allows for the correlation and synthesis of information that would otherwise be incommensurate. The value shows up in scientific circles, social networking applications, commercial settings, command and control systems and a wide range of other uses. The incorporation of a large number of devices on the Internet contributes to this trend. These values will also be realized in space exploration applications and this talk will finish with a brief summary of the state of the art of space networking.

The Internet has been evolving from its origins in the early 1970s, based on work sponsored by the U.S. Defense Advanced Research Projects Agency. While the basic design was known in 1973 and first published in 1974 and the system essentially deployed in the academic and military communities on January 1, 1983, much has happened in the intervening 20 years. The first commercial Internet services emerged in 1989 after the interconnection of the Internet to commercial e-mail services. By 1993, commercial versions of the World Wide Web had appeared, and by 2003, voice over IP service was growing rapidly, after its first commercial introduction around 1995 (See Vocaltec: http://www.vocaltec.com/html/about/company.shtml). The Internet of the future will be shaped by the tectonic forces of regulation, commercialization, technological change, and a wide range of policy concerns expressed at local, national, regional and international levels. In this paper, the effect of these forces is considered and an attempt made to project their effects into the future.

The requirements for the Internet emerged in part from the practical experiences drawn from the development, deployment and use of the ARPANET. Each distinct network would have to stand on its own and no internal changes could be required to any such network to connect it to the Internet. Communications would be on a best effort basis. If a packet didn't make it to the final destination, it would shortly be retransmitted from the source. Black boxes would be used to connect the networks; these would later be called gateways and routers. There would be no information retained by the gateways about the individual flows of packets passing through them, thereby keeping them simple and avoiding complicated adaptation and recovery from various failure modes. There would be no global control at the operations level.

No abstract available.

No abstract available.

A protocol that supports the sharing of resources that exist in different packet switching networks is presented. The protocol provides for variation in individual network packet sizes, transmission failures, sequencing, flow control, end-to-end error checking, and the creation and destruction of logical process-to-process connections. Some implementation issues are considered, and problems such as internetwork routing, accounting, and timeouts are exposed.

The ARPA computer network (ARPANET) is a nationwide network of diverse autonomous computers connected via a message-switching store-and-forward communications subnet using leased wide-band (50-kbit/s) telephone lines. A primary objective of the ARPANET is to share preexisting programs and data. Many of the difficulties of using remotely generated programs and data are found to be simple format incompatibilities requiring data manipulations like character set conversion, header prefacing and stripping, packing and unpacking of repeated data, generating counters and flags, and field transposition. The data reconfiguration service (DRS) is an attempt to provide a convenient way of performing these data manipulations in order to mediate between superficially incompatible data streams connecting existing programs in the ARPANET. Desiring to match two incompatible input-output streams, an applications programmer specifies a data stream transformation (called a form) written in the data reconfiguration language (DRL). Associating the appropriate form name with the connection between his two programs, the programmer causes the DRS to follow his instructions on how the specified data streams are to be manipulated in the communication required to make the two programs cooperate over the ARPANET. Components of the DRS include the specification of its special-purpose data reconfiguration language, a form compiler to translate forms into fast-running transformation programs, an interpreter to perform high-speed data transformations at application program run time, and a standard set of ARPANET protocols for the routine handling of connections and form specifications between operating systems.