SEARCH · Search NASA

Results for “Routers”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

107 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRS2011

NASA Tech Briefs, August 2011

Topics covered include: Miniature, Variable-Speed Control Moment Gyroscope; NBL Pistol Grip Tool for Underwater Training of Astronauts; HEXPANDO Expanding Head for Fastener-Retention Hexagonal Wrench; Diagonal-Axes Stage for Pointing an Optical Communications Transceiver; Improvements in Speed and Functionality of a 670-GHz Imaging Radar; IONAC-Lite; Large Ka-Band Slot Array for Digital Beam-Forming Applications; Development of a 150-GHz MMIC Module Prototype for Large-Scale CMB Radiation; Coupling Between Waveguide-Fed Slot Arrays; PCB-Based Break-Out Box; Multiple-Beam Detection of Fast Transient Radio Sources; Router Agent Technology for Policy-Based Network Management; Remote Asynchronous Message Service Gateway; Automatic Tie Pointer for In-Situ Pointing Correction; Jitter Correction; MSLICE Sequencing; EOS MLS Level 2 Data Processing Software Version 3; DspaceOgre 3D Graphics Visualization Tool; Metallization for Yb14MnSb11-Based Thermoelectric Materials; Solvent/Non-Solvent Sintering To Make Microsphere Scaffolds; Enhanced Fuel-Optimal Trajectory-Generation Algorithm for Planetary Pinpoint Landing; Self-Cleaning Coatings and Materials for Decontaminating Field-Deployable Land and Water-Based Optical Systems; Separation of Single-Walled Carbon Nanotubes with DEP-FFF; Li Anode Technology for Improved Performance; Post-Fragmentation Whole Genome Amplification-Based Method; Microwave Tissue Soldering for Immediate Wound Closure; Principles, Techniques, and Applications of Tissue Microfluidics; Robotic Scaffolds for Tissue Engineering and Organ Growth; Stress-Driven Selection of Novel Phenotypes; Method for Accurately Calibrating a Spectrometer Using Broadband Light; Catalytic Microtube Rocket Igniter; Stage Cylindrical Immersive Display; Vacuum Camera Cooler; Atomic Oxygen Fluence Monitor; Thermal Management Tools for Propulsion System Trade Studies and Analysis; Introduction to Physical Intelligence; Technique for Solving Electrically Small to Large Structures for Broadband Applications; Accelerated Adaptive MGS Phase Retrieval; Large Eddy Simulation Study for Fluid Disintegration and Mixing; Tropospheric Correction for InSAR Using Interpolated ECMWF Data and GPS Zenith Total Delay; Technique for Calculating Solution Derivatives With Respect to Geometry Parameters in a CFD Code; Acute Radiation Risk and BRYNTRN Organ Dose Projection Graphical User Interface; Probabilistic Path Planning of Montgolfier Balloons in Strong, Uncertain Wind Fields; Flight Simulation of ARES in the Mars Environment; Low-Outgassing Photogrammetry Targets for Use in Outer Space; Planning the FUSE Mission Using the SOVA Algorithm; Monitoring Spacecraft Telemetry Via Optical or RF Link; and Robust Thermal Control of Propulsion Lines for Space Missions.

Source record↗

NASA NTRS2013

Remote Memory Access Protocol Target Node Intellectual Property

The MagnetoSpheric Multiscale (MMS) mission had a requirement to use the Remote Memory Access Protocol (RMAP) over its SpaceWire network. At the time, no known intellectual property (IP) cores were available for purchase. Additionally, MMS preferred to implement the RMAP functionality with control over the low-level details of the design. For example, not all the RMAP standard functionality was needed, and it was desired to implement only the portions of the RMAP protocol that were needed. RMAP functionality had been previously implemented in commercial off-the-shelf (COTS) products, but the IP core was not available for purchase. The RMAP Target IP core is a VHDL (VHSIC Hardware Description Language description of a digital logic design suitable for implementation in an FPGA (field-programmable gate array) or ASIC (application-specific integrated circuit) that parses SpaceWire packets that conform to the RMAP standard. The RMAP packet protocol allows a network host to access and control a target device using address mapping. This capability allows SpaceWire devices to be managed in a standardized way that simplifies the hardware design of the device, as well as the development of the software that controls the device. The RMAP Target IP core has some features that are unique and not specified in the RMAP standard. One such feature is the ability to automatically abort transactions if the back-end logic does not respond to read/write requests within a predefined time. When a request times out, the RMAP Target IP core automatically retracts the request and returns a command response with an appropriate status in the response packet s header. Another such feature is the ability to control the SpaceWire node or router using RMAP transactions in the extended address range. This allows the SpaceWire network host to manage the SpaceWire network elements using RMAP packets, which reduces the number of protocols that the network host needs to support.

Haddad, Omar↗

NASA NTRS2013

IT Security Support for the Spaceport Command Control Systems Development Ground Support Development Operations

Security is one of the most if not the most important areas today. After the several attacks on the United States, security everywhere was heightened from Airports to the communication among the military branches legionnaires. With advanced persistent threats (APTs) on the rise following Stuxnet, government branches and agencies are required, more than ever, to follow several standards, policies and procedures to reduce the likelihood of a breach. Attack vectors today are very advanced and are going to continue to get more and more advanced as security controls advance. This creates a need for networks and systems to be in an updated and secured state in a launch control system environment. FISMA is a law that is mandated by the government to follow when government agencies secure networks and devices. My role on this project is to ensure network devices and systems are in compliance with NIST, as outlined in FISMA. I will achieve this by providing assistance with security plan documentation and collection, system hardware and software inventory, malicious code and malware scanning and configuration of network devices i.e. routers and IDSsIPSs. In addition I will be completing security assessments on software and hardware, vulnerability assessments and reporting, conducting patch management and risk assessments. A guideline that will help with compliance with NIST is the SANS Top 20 Critical Controls. SANS Top 20 Critical Controls as well as numerous security tools, security software and the conduction of research will be used to successfully complete the tasks given to me. This will ensure compliance with FISMA and NIST, secure systems and a secured network. By the end of this project, I hope to have carried out stated above as well as gain an immense knowledge about compliance, security tools, networks and network devices, policies and procedures.

computer information security↗

NASA NTRS2012

Dynamic Communication Resource Negotiations

Today's advanced network management systems can automate many aspects of the tactical networking operations within a military domain. However, automation of joint and coalition tactical networking across multiple domains remains challenging. Due to potentially conflicting goals and priorities, human agreement is often required before implementation into the network operations. This is further complicated by incompatible network management systems and security policies, rendering it difficult to implement automatic network management, thus requiring manual human intervention to the communication protocols used at various network routers and endpoints. This process of manual human intervention is tedious, error-prone, and slow. In order to facilitate a better solution, we are pursuing a technology which makes network management automated, reliable, and fast. Automating the negotiation of the common network communication parameters between different parties is the subject of this paper. We present the technology that enables inter-force dynamic communication resource negotiations to enable ad-hoc inter-operation in the field between force domains, without pre-planning. It also will enable a dynamic response to changing conditions within the area of operations. Our solution enables the rapid blending of intra-domain policies so that the forces involved are able to inter-operate effectively without overwhelming each other's networks with in-appropriate or un-warranted traffic. It will evaluate the policy rules and configuration data for each of the domains, then generate a compatible inter-domain policy and configuration that will update the gateway systems between the two domains.

policy negotiation↗

NASA NTRS2014

IT Security Support for the Spaceport Command Control Systems Development Ground Support Development Operations

Security is one of the most if not the most important areas today. After the several attacks on the United States, security everywhere has heightened from airports to the communication among the military branches legionnaires. With advanced persistent threats (APT's) on the rise following Stuxnet, government branches and agencies are required, more than ever, to follow several standards, policies and procedures to reduce the likelihood of a breach. Attack vectors today are very advanced and are going to continue to get more and more advanced as security controls advance. This creates a need for networks and systems to be in an updated and secured state in a launch control system environment. FISMA is a law that is mandated by the government to follow when government agencies secure networks and devices. My role on this project is to ensure network devices and systems are in compliance with NIST, as outlined in FISMA. I will achieve this by providing assistance with security plan documentation and collection, system hardware and software inventory, malicious code and malware scanning, and configuration of network devices i.e. routers and IDS's/IPS's. In addition, I will be completing security assessments on software and hardware, vulnerability assessments and reporting, and conducting patch management and risk assessments. A guideline that will help with compliance with NIST is the SANS Top 20 Critical Controls. SANS Top 20 Critical Controls as well as numerous security tools, security software and the conduction of research will be used to successfully complete the tasks given to me. This will ensure compliance with FISMA and NIST, secure systems and a secured network. By the end of this project, I hope to have carried out the tasks stated above as well as gain an immense knowledge about compliance, security tools, networks and network devices, as well as policies and procedures.

security↗

NASA NTRS2008

Dynamic Routing for Delay-Tolerant Networking in Space Flight Operations

Contact Graph Routing (CGR) is a dynamic routing system that computes routes through a time-varying topology composed of scheduled, bounded communication contacts in a network built on the Delay-Tolerant Networking (DTN) architecture. It is designed to support operations in a space network based on DTN, but it also could be used in terrestrial applications where operation according to a predefined schedule is preferable to opportunistic communication, as in a low-power sensor network. This paper will describe the operation of the CGR system and explain how it can enable data delivery over scheduled transmission opportunities, fully utilizing the available transmission capacity, without knowing the current state of any bundle protocol node (other than the local node itself) and without exhausting processing resources at any bundle router.

CGR↗

NASA NTRS2015

Addressing Software Security

Historically security within organizations was thought of as an IT function (web sites/servers, email, workstation patching, etc.) Threat landscape has evolved (Script Kiddies, Hackers, Advanced Persistent Threat (APT), Nation States, etc.) Attack surface has expanded -Networks interconnected!! Some security posture factors Network Layer (Routers, Firewalls, etc.) Computer Network Defense (IPS/IDS, Sensors, Continuous Monitoring, etc.) Industrial Control Systems (ICS) Software Security (COTS, FOSS, Custom, etc.)

software↗

NASA NTRS2016

Essential SpaceWire Hardware Capabilities for a Robust Network

The Geostationary Operational Environmental Satellite R-Series Program (GOES-R) mission is a joint program between National Oceanic & Atmospheric Administration (NOAA) and National Aeronautics & Space Administration (NASA) Goddard Space Flight Center (GSFC). GOES-R project selected SpaceWire as the best solution to satisfy the desire for simple and flexible instrument to spacecraft command and telemetry communications. GOES-R development and integration is complete and the observatory is scheduled for launch October 2016. The spacecraft design was required to support redundant SpaceWire links for each instrument side, as well as to route the fewest number of connections through a Slip Ring Assembly necessary to support Solar pointing instruments. The final design utilized two different router designs. The SpaceWire standard alone does not ensure the most practical or reliable network. On GOES-R a few key hardware capabilities were identified that merit serious consideration for future designs. Primarily these capabilities address persistent port stalls and the prevention of receive buffer overflows. Workarounds were necessary to overcome shortcomings that could be avoided in future designs if they utilize the capabilities, discussed in this paper, above and beyond the requirements of the SpaceWire standard.

SpaceWire↗

NASA NTRS2017

Mesh Network Architecture for Enabling Inter-Spacecraft Communication

To enable communication between spacecraft operating in a formation or small constellation, a mesh network architecture was developed and tested using a time division multiple access (TDMA) communication scheme. The network is designed to allow for the exchange of telemetry and other data between spacecraft to enable collaboration between small spacecraft. The system uses a peer-to-peer topology with no central router, so that it does not have a single point of failure. The mesh network is dynamically configurable to allow for addition and subtraction of new spacecraft into the communication network. Flight testing was performed using an unmanned aerial system (UAS) formation acting as a spacecraft analogue and providing a stressing environment to prove mesh network performance. The mesh network was primarily devised to provide low latency, high frequency communication but is flexible and can also be configured to provide higher bandwidth for applications desiring high data throughput. The network includes a relay functionality that extends the maximum range between spacecraft in the network by relaying data from node to node. The mesh network control is implemented completely in software making it hardware agnostic, thereby allowing it to function with a wide variety of existing radios and computing platforms..

Becker, Christopher↗

NASA NTRS2017

A Machine Learning Concept for DTN Routing

This paper discusses the concept and architecture of a machine learning based router for delay tolerant space networks. The techniques of reinforcement learning and Bayesian learning are used to supplement the routing decisions of the popular Contact Graph Routing algorithm. An introduction to the concepts of Contact Graph Routing, Q-routing and Naive Bayes classification are given. The development of an architecture for a cross-layer feedback framework for DTN (Delay-Tolerant Networking) protocols is discussed. Finally, initial simulation setup and results are given.

Delay Tolerant Networks↗

NASA NTRS2018

Research and Development of The Immersive Simulations and Engineering Environment

March of 2018 marked the conclusion of the primary updates to the immersive Simulations and Engineering Environment (iSEE) at Kennedy Space Center (KSC). Many of the problems that had arisen during the previous semester have been addressed and rectified. These included the malfunction to one of the lab's primary routers, the inefficiency of the capture environment, and various interface issues in the analysis software, Jack. This semester was primarily research and development oriented with some focus on implementation of the new hardware and software that was received last semester. The new computers and cameras that arrived sometime during the winter were installed, and the lab received its second operation opportunity. The second operation was a major milestone for the lab, both in terms of what the abilities were and what can be learned from its use. The operation performed was a virtual simulation of a critical task that would occur, if it should be needed, in the Multi Payload Processing Facility. It was done to gather human factors data on its safety and process controls. The technicians were able to come to a number of conclusions about how to perform their task as a result of utilizing iSEE. Another key breakthrough this semester was the introduction to Jack Script, a scripting language built into our analysis software that further extend Jack capabilities. In addition to the aforementioned, many preparations were made for family day, an exposition for KSC families to come out and tour the spaceport. Due to family day being moved to the spring, the video made last fall had to be updated with recent environment changes in preparation for the Family Day demonstrations.

Motion Capture↗

NASA NTRS2017

Expanding a Supercomputer Facility Using Modular Data Center Technology

With the expansion of high-end computing resources needed to support NASA's increasing demands for physics-based simulations, the facility housing Pleiades-the agency's largest supercomputer-recently reached its power and cooling capacity. In response, the NASA Advanced Supercomputing Division at Ames Research Center undertook a prototype project that resulted in a new facility based on modular data center technology. The facility, a ~1000 square-foot module on a concrete pad with room for 16-18 compute racks, was completed in fall 2016 and an SGI computer system, named Electra, was deployed there in early 2017. Cooling is performed via an evaporative system built into the module, and preliminary experience shows a Power Usage Effectiveness (PUE) of ~1.03. Electra achieved over a petaflop on the LINPACK benchmark, sufficient to rank number 96 on the November 2016 TOP500 list. The system consists of 1,152 InfiniBand-connected Intel Xeon Broadwell-based nodes. Its users access their files on a facility wide file system shared by all compute assets via Mellanox MetroX InfiniBand extenders, which connect the Electra fabric to Lustre routers InfiniBand fabric over fiber-optic links about 300 meters long. The prototype has exceeded expectations and is serving as a blueprint for future expansions.*†

Facility↗

NASA NTRS2019

Electra: A Modular-Based Expansion of NASA's Supercomputing Capability

NASA has increasingly relied on high-performance computing (HPC) re- sources for computational modeling, simulation, and data analysis to meet the science and engineering goals of its missions in space exploration, aeronautics, and Earth and space science. The NASA Advanced Supercomputing (NAS) Division at Ames Research Center in Silicon Valley, Calif., hosts NASA’s premier supercomputing resources, integral to achieving and enhancing the success of the agency’s missions. NAS provides a balanced environment, funded under the High-End Computing Capability (HECC) project, comprised of world-class supercomputers, including its flagship distributed-memory cluster, Pleiades; high-speed networking; and massive data storage facilities, along with multi-disciplinary support teams for user support, code porting and optimization, and large-scale data analysis and scientific visualization. However, as scientists have increased the fidelity of their simulations and engineers are conducting larger parameter-space studies, the requirements for supercomputing resources have been growing by leaps and bounds. With the facility housing the HECC systems reaching its power and cooling capacity, NAS undertook a prototype project to investigate an alternative approach for housing supercomputers. Modular supercomputing, or container-based computing, is an innovative concept for expanding NASA’s HPC capabilities. With modular supercomputing, additional containers—similar to portable storage pods—can be connected together as needed to accommodate the agency’s ever-increasing demand for computing resources. In addition, taking advantage of the local weather permits the use of cooling technologies that would additionally save energy and reduce annual water usage. The first stage of NASA’s Modular Supercomputing Facility (MSF) prototype, which resulted in a 1,000 square-foot module on a concrete pad with room for 16 compute racks, was completed in Fall 2016 and an SGI (now HPE) computer system, named Electra, was deployed there in early 2017. Cooling is performed via an evaporative system built into the module, and preliminary experience shows a Power Usage Effectiveness (PUE) measurement of 1.03. Electra achieved over a petaflop on the LINPACK benchmark, sufficient to rank number 96 on the November 2016 TOP500 list [14]. The system consists of 1,152 InfiniBand-connected Intel Xeon Broadwell-based nodes. Its users access their files on a facility-wide file system shared by all HECC compute assets via Mellanox MetroX InfiniBand extenders, which connect the Electra fabric to Lustre routers in the primary facility over fiber-optic links about 900 feet long. The MSF prototype has exceeded expectations and is serving as a blueprint for future expansions. In the remainder of this chapter, we detail how modular data center technology can be used to expand an existing compute resource. We begin by describing NASA’s requirements for supercomputing and how resources were provided prior to the integration of the Electra module-based system.

Biswas, Rupak↗

NASA NTRS2021

PatchworkWave: A Multipatch Infrastructure for Multiphysics/Multiscale/Multiframe/Multimethod Simulations at Arbitrary Order

We present an extension of the PatchworkMHD code [1], itself an MHD-capable extension of thePatch-workcode [2], for which several algorithms presented here were co-developed. Its purpose is to create a“multipatch” scheme compatible with numerical simulations of arbitrary equations of motion at any dis-cretization order in space and time. In thePatchworkframework, the global simulation is comprised of anarbitrary number of moving, local meshes, or “patches”, which are free to employ their own resolution, co-ordinate system/topology, physics equations, reference frame, and in our new approach, numerical method.Each local patch exchanges boundary data with a single global patch on which all other patches residethrough a client-router-server parallelization model. In generalizingPatchworkto be compatible witharbitrary order time integration,PatchworkMHDandPatchworkWavehave significantly improved theinterpatch interpolation accuracy by removing an interpolation of interpolated data feedback present in theoriginalPatchworkcode. Furthermore, we extendPatchworkto bemultimethodby allowing multiplestate vectors to be updated simultaneously, with each state vector providing its own interpatch interpolationand transformation procedures. As such, our scheme is compatible with nearly any set of hyperbolic partialdifferential equations. We demonstrate our changes through the implementation of a scalar wave toy-modelthat is evolved on arbitrary, time dependent patch configurations at 4th order accuracy.

Dennis B Bowen↗

NASA NTRSDate not supplied

Next Steps: Laying the Groundwork for Bundle Protocol v7

Delay/Disruption Tolerant Networking (DTN) is a networking model and protocol suite that extends the terrestrial internet to the challenging communication environments of space. These environments are typically subject to frequent disruptions, which can cause delays or errors. DTN protects data transmission by wrapping data into bundles (similar to Internet Protocol packets), storing them until a connection can be established between two nodes (similar to terrestrial routers or computers), and forwarding them to their destinations. Bundle Protocol (BP) is responsible for generating those bundles and creates the transport layer of DTN, much like how Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) create the transport layer of the Internet Protocol. BPv6 is the current, accepted version of the Bundle Protocol standard. However, recent missions and test implementations have revealed missing components and areas for improvement in the standard. Using lessons learned from NASA missions and gathering inspiration from the Internet Protocol, BPv7 is intended to be a more robust Bundle Protocol that improves upon its predecessor and increases the technology readiness level of the DTN architecture. The DTN Standard Interface Design team, a sub-team of the DTN Infusion Project at the Goddard Space Flight Center, worked to create a dictionary of terms for bundle components and functional decomposition of the protocol. These efforts aided in the standardization of BP interfaces, something missing from BPv6, and supported parallel network management and configuration work. This standardization will ultimately contribute to LunaNet (a lunar communications and navigation architecture that will bring networking, positioning, navigation, timing and science services to the Moon), the Solar System Internet (SSI), and expand crewed and uncrewed space exploration opportunities.

DTN↗

NASA NTRSDate not supplied

Next Steps: Laying the Groundwork for Bundle Protocol v7

dtn↗

NASA NTRSDate not supplied

Towards Sheaf Theoretic Analyses for Delay Tolerant Networking

The goal of Delay Tolerant Networking (DTN) is to take a collection of heterogeneous, disparate connections between satellites, space assets, ground stations, and ground infrastructure and bring it together into a cohesive, functioning overlay network. Depending on the systems being considered, one can find links with a one-way light time exceeding minutes (and hours),periodic links which can sometimes be predicted by orbital mechanics, and restrictions based on the variety of capabilities built into these systems. These characteristics preclude traditional network models and routing techniques and have classically led to either rigid routing tables or purely probabilistic models. As the deeper underlying structures remain unknown, development of more DTN-optimized algorithms has lacked the necessary foundation. In a continuation of previous work, the goal of this paper is to identify and study these fundamental structures that exist in delay tolerant networks (DTN), with a focus on space networks. The current routing methodology has been to use contact graph routing (CGR) algorithms. CGR models a series of known contacts as a static graph. For CGR to work, this graph must be globally consistent and must have an accurate picture of the network. Because this is a globally controlled structure, there is little room for flexibility in the event of changes to the network which would naturally occur as the network grows. As a response to the desire for flexibility as the network changes, we introduced the mathematical structure known as sheaves to DTNs last year. The tag-line for sheaves is that they are a mathematically precise way of gluing local data together into unique global data. Thus, sheaves lend extra power to traditional models(and routing algorithms) by taking additional information and merging it, in as consistent a manner as possible, with the representation itself. The clearest example of how Earth-bound networks exhibit behavior that is “sheafy” is link state routers, which build a local-to-global picture of their network by gluing local information together into a global network, exactly as a sheaf would do. For routing within delay tolerant networks to truly exploit this structure, a deeper structure than a graph is required. In this paper, we develop sheaves that can work over directed graphs such as temporal flow networks, we construct a sheaf representation for Dijkstra’s algorithm, and we outline a construction for routing sheaves capable of modeling multicast scenarios. Finally, there is a section of future work suggesting follow-on research.

Robert Short↗