SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
We present a technique that derives the link activation schedule (transmit/receive mode and communications neighbor selection) and routes used for efficient traffic relay through the network.
Network layer mobility allows transport protocols to maintain connection state, despite changes in a node's physical location and point of network connectivity. However, some congestion-controlled transport protocols are not designed to deal with these rapid and potentially significant path changes. In this paper we demonstrate several distinct problems that mobility-induced path changes can create for TCP performance. Our premise is that mobility events indicate path changes that require re-initialization of congestion control state at both connection end points. We present the application of this idea to TCP in the form of a simple solution (the Lightweight Mobility Detection and Response algorithm, that has been proposed in the IETF), and examine its effectiveness. In general, we find that the deficiencies presented are both relatively easily and painlessly fixed using this solution. We also find that this solution has the counter-intuitive property of being both more friendly to competing traffic, and simultaneously more aggressive in utilizing newly available capacity than unmodified TCP.
High-fidelity quantum entanglement enables key quantum networking capabilities such as secure communication and distributed quantum computing, but long-distance entanglement distribution is limited by noise and loss. Entanglement distillation protocols address this problem by extracting high-fidelity Bell pairs from multiple noisy ones. The primary objective is minimizing the resource overhead: the number of noisy input pairs needed to distill each high-fidelity output pair. While protocols achieving optimal overhead are known in theory, they often require complex decoding operations that make practical implementation challenging. We circumvent this challenge by introducing protocols that use quantum scrambling—the spreading of quantum information under chaotic dynamics—through random Clifford operations. Based on this scrambling mechanism, our protocol maintains asymptotically constant overhead, independent of the desired output error rate $\bar{𝜖}$ , and can be implemented with shallow quantum circuits of depth 𝑂(poly log log $\bar{𝜖}$ −1 ) and memory 𝑂(poly log $\bar{𝜖}$ −1 ). Our protocol remains effective even with noisy quantum gates. By incorporating error correction, our protocol achieves state-of-the-art performance: starting with pairs of 10% initial infidelity, we require only seven noisy inputs per output pair to distill a single Bell pair with infidelity $\bar{𝜖}$ =10 −12 , substantially outperforming existing schemes. We demonstrate the utility of our protocols for quantum repeater networks.
This is a Design Specification for a gateway to interconnect fiber optic local area networks (LAN's). The internetworking protocols for a gateway device that will interconnect multiple local area networks are defined. This specification serves as input for preparation of detailed design specifications for the hardware and software of a gateway device. General characteristics to be incorporated in the gateway such as node address mapping, packet fragmentation, and gateway routing features are described.
Routing in Delay-/Disruption-Tolerant Networking (DTN) has long been recognized as a challenging research topic. The difficulty lies in the fact that link intermittency and network partitioning, possibly coupled with long delays, prevent the use of Internet solutions based on an up-to-date comprehensive knowledge of network topology, as communicated by routing protocols. In the literature on DTN routing, there is a dichotomy between solutions designed for deterministic (e.g., space flight) networks, such as Contact Graph Routing (CGR), and the wide variety of protocols designed for opportunistic terrestrial networks. After a discussion of the origin and motivations of this duality, the paper presents an opportunistic extension of CGR (OCGR). The aim is to try to resolve the DTN routing dichotomy by providing a unified approach suitable for all DTN environments.
This software implements bundle authentication, conforming to the Delay-Tolerant Networking (DTN) Internet Draft on Bundle Security Protocol (BSP), for the Interplanetary Overlay Network (ION) implementation of DTN. This is the only implementation of BSP that is integrated with ION.
Satellite and terrestrial cellular systems naturally complement each other for land mobile communications, even though present systems have been developed independently. The main advantages of the integrated system are a faster wide area coverage, a better management of overloading traffic conditions, an extension to geographical areas not covered by the terrestrial network and, in perspective, the provision of only one integrated system for all mobile communications (land, aeronautical, and maritime). To achieve these goals, as far as possible the same protocols of the terrestrial network should be used also for the satellite network. Discussed here are the main issues arising from the requirements of the main integrated system. Some results are illustrated, and possible future improvements due to technical solutions are presented.
As on-board satellite systems continue to increase in ability to perform self diagnostic checks, it will become more important for satellites to initiate ground communications contact. Currently, the NASA Space Network requires users to pre-arranged times for satellite communications links through the Tracking and Data Relay Satellite (TDRS). One of the challenges in implementing an on-demand access protocol into the Space Network, is the fact that a low Earth orbiting (LEO) satellite's communications will be subject to a doppler shift which is outside the capability of the NASA ground station to lock onto. In a prearranged system, the satellite's doppler is known a priori, and the ground station is able to lock onto the satellite's signal. This paper describes the development of a high speed analog to digital interface into a Digital Signal Processor (DSP). This system will be used for identifying the doppler shift of a LEO satellite through the Space Network, and aiding the ground station equipment in locking onto the signal. Although this interface is specific to one application, it can be used as a basis for interfacing other devices with a DSP.
The NASA Science Internet, (NSI) was established in 1987 to provide NASA's Offices of Space Science and Applications (OSSA) missions with transparent wide-area data connectivity to NASA's researchers, computational resources, and databases. The NSI Office at NASA/Ames Research Center has the lead responsibility for implementing a total, open networking program to serve the OSSA community. NSI is a full-service communications provider whose services include science network planning, network engineering, applications development, network operations, and network information center/user support services. NSI's mission is to provide reliable high-speed communications to the NASA science community. To this end, the NSI Office manages and operates the NASA Science Internet, a multiprotocol network currently supporting both DECnet and TCP/IP protocols. NSI utilizes state-of-the-art network technology to meet its customers' requirements. THe NASA Science Internet interconnects with other national networks including the National Science Foundation's NSFNET, the Department of Energy's ESnet, and the Department of Defense's MILNET. NSI also has international connections to Japan, Australia, New Zealand, Chile, and several European countries. NSI cooperates with other government agencies as well as academic and commercial organizations to implement networking technologies which foster interoperability, improve reliability and performance, increase security and control, and expedite migration to the OSI protocols.
This version of the SpaceCube will be a full-fledged, onboard space processing system capable of 2500+ MIPS, and featuring a number of plug-andplay gigabit and standard interfaces, all in a condensed 3x3x3 form factor [less than 10 watts and less than 3 lb (approximately equal to 1.4 kg)]. The main processing engine is the Xilinx SIRF radiation- hardened-by-design Virtex-5 FX-130T field-programmable gate array (FPGA). Even as the SpaceCube 2.0 version (currently under test) is being targeted as the platform of choice for a number of the upcoming Earth Science Decadal Survey missions, GSFC has been contacted by customers who wish to see a system that incorporates key features of the version 2.0 architecture in an even smaller form factor. In order to fulfill that need, the SpaceCube Mini is being designed, and will be a very compact and low-power system. A similar flight system with this combination of small size, low power, low cost, adaptability, and extremely high processing power does not otherwise exist, and the SpaceCube Mini will be of tremendous benefit to GSFC and its partners. The SpaceCube Mini will utilize space-grade components. The primary processing engine of the Mini is the Xilinx Virtex-5 SIRF FX-130T radiation-hardened-by-design FPGA for critical flight applications in high-radiation environments. The Mini can also be equipped with a commercial Xilinx Virtex-5 FPGA with integrated PowerPCs for a low-cost, high-power computing platform for use in the relatively radiation- benign LEOs (low-Earth orbits). In either case, this version of the Space-Cube will weigh less than 3 pounds (.1.4 kg), conform to the CubeSat form-factor (10x10x10 cm), and will be low power (less than 10 watts for typical applications). The SpaceCube Mini will have a radiation-hardened Aeroflex FPGA for configuring and scrubbing the Xilinx FPGA by utilizing the onboard FLASH memory to store the configuration files. The FLASH memory will also be used for storing algorithm and application code for the PowerPCs and the Xilinx FPGA. In addition, it will feature highspeed DDR SDRAM (double data rate synchronous dynamic random-access memory) to store the instructions and data of active applications. This version will also feature SATA-II and Gigabit Ethernet interfaces. Furthermore, there will also be general-purpose, multi-gigabit interfaces. In addition, the system will have dozens of transceivers that can support LVDS (low-voltage differential signaling), RS-422, or SpaceWire. The SpaceCube Mini includes an I/O card that can be customized to meet the needs of each mission. This version of the SpaceCube will be designed so that multiple Minis can be networked together using SpaceWire, Ethernet, or even a custom protocol. Scalability can be provided by networking multiple SpaceCube Minis together. Rigid-Flex technology is being targeted for the construction of the SpaceCube Mini, which will make the extremely compact and low-weight design feasible. The SpaceCube Mini is designed to fit in the compact CubeSat form factor, thus allowing deployment in a new class of missions that the previous SpaceCube versions were not suited for. At the time of this reporting, engineering units should be available in the summer 2012.
Implemented security protocols are basically pieces of software which are used to (a) authenticate the other communication partners, (b) establish a secure communication channel between them (using insecure communication media), and (c) transfer data between the communication partners in such a way that these data only available to the desired receiver, but not to anyone else. Such an implementation usually consists of the following components: the protocol-engine, which controls in which sequence the messages of the protocol are sent over the network, and which controls the assembly/disassembly and processing (e.g., decryption) of the data. the cryptographic routines to actually encrypt or decrypt the data (using given keys), and t,he interface to the operating system and to the application. For a correct working of such a security protocol, all of these components must work flawlessly. Many formal-methods based techniques for the analysis of a security protocols have been developed. They range from using specific logics (e.g.: BAN-logic [4], or higher order logics [12] to model checking [2] approaches. In each approach, the analysis tries to prove that no (or at least not a modeled intruder) can get access to secret data. Otherwise, a scenario illustrating the &tack may be produced. Despite the seeming simplicity of security protocols ("only" a few messages are sent between the protocol partners in order to ensure a secure communication), many flaws have been detected. Unfortunately, even a perfect protocol engine does not guarantee flawless working of a security protocol, as incidents show. Many break-ins and security vulnerabilities are caused by exploiting errors in the implementation of the protocol engine or the underlying operating system. Attacks using buffer-overflows are a very common class of such attacks. Errors in the implementation of exception or error handling can open up additional vulnerabilities. For example, on a website with a log-in screen: multiple tries with invalid passwords caused the expected error message (too many retries). but let the user nevertheless pass. Finally, security can be compromised by silly implementation bugs or design decisions. In a commercial VPN software, all calls to the encryption routines were incidentally replaced by stubs, probably during factory testing. The product worked nicely. and the error (an open VPN) would have gone undetected, if a team member had not inspected the low-level traffic out of curiosity. Also, the use secret proprietary encryption routines can backfire, because such algorithms often exhibit weaknesses which can be exploited easily (see e.g., DVD encoding). Summarizing, there is large number of possibilities to make errors which can compromise the security of a protocol. In today s world with short time-to-market and the use of security protocols in open and hostile networks for safety-critical applications (e.g., power or air-traffic control), such slips could lead to catastrophic situations. Thus, formal methods and automatic reasoning techniques should not be used just for the formal proof of absence of an attack, but they ought to be used to provide an end-to-end tool-supported framework for security software. With such an approach all required artifacts (code, documentation, test cases) , formal analyses, and reliable certification will be generated automatically, given a single, high level specification. By a combination of program synthesis, formal protocol analysis, certification; and proof-carrying code, this goal is within practical reach, since all the important technologies for such an approach actually exist and only need to be assembled in the right way.
Space Exploration missions requires the design and implementation of space networking that differs from terrestrial networks. In a space networking architecture, interplanetary communication protocols need to be designed, validated and evaluated carefully to support different mission requirements. As actual systems are expensive to build, it is essential to have a low cost method to validate and verify mission/system designs and operations. This can be accomplished through simulation. Simulation can aid design decisions where alternative solutions are being considered, support trade-studies and enable fast study of what-if scenarios. It can be used to identify risks, verify system performance against requirements, and as an initial test environment as one moves towards emulation and actual hardware implementation of the systems. We describe the development of Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE) and its use cases in supporting architecture trade studies, protocol performance and its role in hybrid simulation/emulation. The MACHETE environment contains various tools and interfaces such that users may select the set of tools tailored for the specific simulation end goal. The use cases illustrate tool combinations for simulating space networking in different mission scenarios. This simulation environment is useful in supporting space networking design for planned and future missions as well as evaluating performance of existing networks where non-determinism exist in data traffic and/or link conditions.
Practical Simulator Network (PSimNet) is a set of data-communication protocols designed especially for use in handling messages between computers that are engaging cooperatively in real-time or nearly-real-time training simulations. In a typical application, computers that provide individualized training at widely dispersed locations would communicate, by use of PSimNet, with a central host computer that would provide a common computational- simulation environment and common data. Originally intended for use in supporting interfaces between training computers and computers that simulate the responses of spacecraft scientific payloads, PSimNet could be especially well suited for a variety of other applications -- for example, group automobile-driver training in a classroom. Another potential application might lie in networking of automobile-diagnostic computers at repair facilities to a central computer that would compile the expertise of numerous technicians and engineers and act as an expert consulting technician.
The Interplanetary Overlay Network (ION) software at JPL is an implementation of Delay/Disruption Tolerant Networking (DTN) which has been proposed as an interplanetary protocol to support space communication. The JPL Deep Impact Network (DINET) is a technology development experiment intended to increase the technical readiness of the JPL implemented ION suite. The DINET Experiment Operations Center (EOC) developed by JPL's Protocol Technology Lab (PTL) was critical in accomplishing the experiment. EOC, containing all end nodes of simulated spaces and one administrative node, exercised publish and subscribe functions for payload data among all end nodes to verify the effectiveness of data exchange over ION protocol stacks. A Monitor and Control System was created and installed on the administrative node as a multi-tiered internet-based Web application to support the Deep Impact Network Experiment by allowing monitoring and analysis of the data delivery and statistics from ION. This Monitor and Control System includes the capability of receiving protocol status messages, classifying and storing status messages into a database from the ION simulation network, and providing web interfaces for viewing the live results in addition to interactive database queries.
The High-rate Delay Tolerant Networking (HDTN) project at the NASA Glenn Research Center (GRC) is developing a performance-optimized Delay Tolerant Networking (DTN) implementation using the Bundle Protocol (BP) both for infusion in modern, distributed spacecraft systems and for foundational network research purposes. While one purpose of networking is to enable a returns-to-scale with communicating assets, it is recognized that neither the protocol nor its implementations may impose a bottleneck on data delivery if expected to be implemented. With this in mind, this paper explores the current status of the HDTN software, including its capabilities and also various performance metrics at the bundle layer, the convergence layers (e.g. performance-optimized Licklider Transmission Protocol, or LTP), and bundle storage and retrieval. This includes goals of software implementations that support multi-gigabit per second communications regardless of payload size. A discussion on the current software architecture and internal scheduling and routing is included. Interoperability with such extant DTN implementations as Interplanetary Overlay Network (ION) and DTN Marshall Enterprise Implementation (DTNME) are included. The research goals of the project are also listed, including Software-Defined Networking (SDN) and the theory of DTNs. A table-based filtration system for the Bundle Protocol (BP), called BP Filter, is also explored: this addition enables table-based policies within the context of a DTN for management purposes. Infusion begins with systems testing in the Johnson Space Center (JSC) Software Development and Integration Laboratory (SDIL), which supports International Space Station (ISS) Flight Software development, integration, and verification. Observations made from the results of testing in the SDIL and in flight testing are also discussed, pointing to a path for infusion into high data return low-earth orbit (LEO) missions. The paper concludes with areas for future work.
The Advanced Communications Technology Satellite (ACTS) is operated by the NASA Glenn Research Center at Lewis Field 24 hours a day, 7 days a week. ACTS, which was launched in September 1993, is in its 7th year of operations, far exceeding the system s planned 2 years of operations and 4 years of designed mission life. After 5 successful years of operating as a geostationary satellite, the spacecraft s North-South stationkeeping was discontinued in August 1998. The system is now operating in an inclined orbit that increases at a rate of 0.8 /yr. With only scarce fuel remaining, operating in this mode extends the usage of the still totally functional payload. Although tracking systems are now needed on the experimenter Earth stations, experiment operations have continued with very little disruption. This is the only known geosynchronous Ka-band (30/20 GHz) spot-beam satellite operating in an inclined orbit. The project began its transition from geostationary operations to inclined operations in August 1998. This did not interrupt operations and was transparent to the experimenters on the system. For the space segment, new daily procedures were implemented to maintain the pointing of the system s narrow 0.3 spot beams while the spacecraft drifts in the North-South direction. For the ground segment, modifications were designed, developed, and fielded for the three classes of experimenter Earth stations. With the next generation of commercial satellite systems still being developed, ACTS remains the only operational testbed for Ka-band geosynchronous satellite communications over the Western hemisphere. Since inclined orbit operations began, the ACTS experiments program has supported 43 investigations by industry, Government, and academic organizations, as well as four demonstrations. The project s goals for inclined-orbit operations now reflect a narrower focus in the types of experiments that will be done. In these days of "faster, better, cheaper," NASA is seeking to gain greater relevance to the agency s mission from these experiments. One area that is of much interest both to NASA and the commercial world is the investigation of protocol issues related to the interoperability of satellites with terrestrial networks, such as Transmission Control Protocol/Internet Protocol (TCP/IP) and Asynchronous Transfer Mode (ATM) over wideband satellites. Other experiment areas of interest are supporting the U.S. Government and NASA as they begin using commercial space assets to meet their communications needs, evaluating issues related to operating a spot-beam satellite in inclined orbit, and evaluating new Ka-band hardware that requires a satellite link. ACTS is now in its last year of operations. Operations are planned through June 2000, when after 81 months of operations, this very successful spacecraft will be superorbited and made inert.
The development of the HTTP protocol has been driven by the need to improve the network performance of the protocol by allowing the efficient retrieval of multiple parts of a web page without the need for multiple simultaneous TCP connections between a client and a server. We suggest that the retrieval of multiple page elements sequentially over a single TCP connection may result in a degradation of the perceived performance experienced by the user. We attempt to quantify this perceived degradation through the use of a model which combines a web retrieval simulation and an analytical model of TCP operation. Starting with the current HTTP/l.1 specification, we first suggest a client@side heuristic to improve the perceived transfer performance. We show that the perceived speed of the page retrieval can be increased without sacrificing data transfer efficiency. We then propose a new client/server extension to the HTTP/l.1 protocol to allow for the interleaving of page element retrievals. We finally address the issue of the display of advertisements on web pages, and in particular suggest a number of mechanisms which can make efficient use of IP multicast to send advertisements to a number of clients within the same network.
Contact Graph Routing (CGR) is a dynamic routing system that computes routes through a time-varying topology of scheduled communication contacts in a network based on the DTN (Delay-Tolerant Networking) architecture. It is designed to enable dynamic selection of data transmission routes in a space network based on DTN. This dynamic responsiveness in route computation should be significantly more effective and less expensive than static routing, increasing total data return while at the same time reducing mission operations cost and risk. The basic strategy of CGR is to take advantage of the fact that, since flight mission communication operations are planned in detail, the communication routes between any pair of bundle agents in a population of nodes that have all been informed of one another's plans can be inferred from those plans rather than discovered via dialogue (which is impractical over long one-way-light-time space links). Messages that convey this planning information are used to construct contact graphs (time-varying models of network connectivity) from which CGR automatically computes efficient routes for bundles. Automatic route selection increases the flexibility and resilience of the space network, simplifying cross-support and reducing mission management costs. Note that there are no routing tables in Contact Graph Routing. The best route for a bundle destined for a given node may routinely be different from the best route for a different bundle destined for the same node, depending on bundle priority, bundle expiration time, and changes in the current lengths of transmission queues for neighboring nodes; routes must be computed individually for each bundle, from the Bundle Protocol agent's current network connectivity model for the bundle s destination node (the contact graph). Clearly this places a premium on optimizing the implementation of the route computation algorithm. The scalability of CGR to very large networks remains a research topic. The information carried by CGR contact plan messages is useful not only for dynamic route computation, but also for the implementation of rate control, congestion forecasting, transmission episode initiation and termination, timeout interval computation, and retransmission timer suspension and resumption.