Results for “bundle protocol” — Page 4

NASA NTRS2023

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

NASA NTRS2024

High-Rate Delay Tolerant Networking (HDTN) User Guide Version 1.3.0

Delay Tolerant Networking (DTN) has been identified as a key technology to enable and facilitate the development and growth of future space networks. Classically, space communications networks are collections of disparate links that are manually managed either point-to-point or use space relays. The accelerating accessibility of space enables a new scaling of space nodes, yet both the manual management of configurations and scheduling and the lack of structure connecting links precisely prohibit scaling. This challenge gives rise to newer and larger classes of communications needs that are met by DTN, which must overcome the disconnection, disruption, latency, and mobility featured in space communications systems. DTN joins the underlying links as an overlay, and can be made to communicate over any protocol stack. The core actions of DTN are store, carry, and forward, where data are stored instead of dropped if there is no immediately available outduct. It does this by taking the DTN unit of data, bundles, and providing necessary layers to adapt these bundles to the underlying transport protocols of choice; these are called convergence layers. DTN's Bundle Protocol (BP) can then be used on top of terrestrial protocol stacks, such as TCP/IP, as well as protocols for space, such as LTP/AOS, all in the same network. For emphasis it is noted that bundles can be of essentially any size, and hence this convergence to lower layers of choice is necessary. Existing DTN implementations have operated in constrained environments with limited resources, resulting in low data speeds. However, as various technologies have advanced, data transfer rates and efficiency have advanced, which has pushed the need for a DTN implementation for ground systems and for spacecraft that is performance-oriented in order to not impose an unnecessary bottleneck. High-rate Delay Tolerant Networking (HDTN) takes advantage of modern hardware platforms to substantially reduce latency and improve throughput compared to today’s DTN operations. The HDTN implementation maintains interoperability with existing deployments of DTN that conform to IETF RFCs 4838, 5050, and 9171. At the same time, HDTN defines a new data format better suited to higher-rate operation. It defines and adopts a massively parallel pipelined and message-oriented architecture, allowing the system to scale gracefully as its resources increase. HDTN’s architecture also supports hooks to replace various processing pipeline elements with specialized hardware accelerators. This offers improved Size, Weight, and Power (SWaP) characteristics while reducing development complexity and cost.

Delay Tolerant Networking↗

NASA NTRS2012

Naming in Delay-Tolerant Networking

No abstract available

Delay-Tolerant Networking↗

NASA NTRS2008

The Interplanetary Overlay Networking Protocol Accelerator

A document describes the Interplanetary Overlay Networking Protocol Accelerator (IONAC) an electronic apparatus, now under development, for relaying data at high rates in spacecraft and interplanetary radio-communication systems utilizing a delay-tolerant networking protocol. The protocol includes provisions for transmission and reception of data in bundles (essentially, messages), transfer of custody of a bundle to a recipient relay station at each step of a relay, and return receipts. Because of limitations on energy resources available for such relays, data rates attainable in a conventional software implementation of the protocol are lower than those needed, at any given reasonable energy-consumption rate. Therefore, a main goal in developing the IONAC is to reduce the energy consumption by an order of magnitude and the data-throughput capability by two orders of magnitude. The IONAC prototype is a field-programmable gate array that serves as a reconfigurable hybrid (hardware/ firmware) system for implementation of the protocol. The prototype can decode 108,000 bundles per second and encode 100,000 bundles per second. It includes a bundle-cache static randomaccess memory that enables maintenance of a throughput of 2.7Gb/s, and an Ethernet convergence layer that supports a duplex throughput of 1Gb/s.

Pang, Jackson↗

NASA NTRS1986

Implementation of Ada protocols on Mil-STD-1553 B data bus

Standardization activity of data communication in avionic systems started in 1968 for the purpose of total system integration and the elimination of heavy wire bundles carrying signals between various subassemblies. The growing complexity of avionic systems is straining the capabilities of MIL-STD-1553 B (first issued in 1973), but a much greater challenge to it is posed by Ada, the standard language adopted for real-time, computer embedded-systems. Hardware implementation of Ada communication protocols in a contention/token bus or token ring network is proposed. However, during the transition period when the current command/response multiplex data bus is still flourishing and the development environment for distributed multi-computer Ada systems is as yet lacking, a temporary accomodation of the standard language with the standard bus could be very useful and even highly desirable. By concentrating all status informtion and decisions at the bus controller, it was found to be possible to construct an elegant and efficient harware impelementation of the Ada protocols at the bus interface. This solution is discussed.

Ruhman, Smil↗

NASA NTRS2005

Autonomous Congestion Control in Delay-Tolerant Networks

Congestion control is an important feature that directly affects network performance. Network congestion may cause loss of data or long delays. Although this problem has been studied extensively in the Internet, the solutions for Internet congestion control do not apply readily to challenged network environments such as Delay Tolerant Networks (DTN) where end-to-end connectivity may not exist continuously and latency can be high. In DTN, end-to-end rate control is not feasible. This calls for congestion control mechanisms where the decisions can be made autonomously with local information only. We use an economic pricing model and propose a rule-based congestion control mechanism where each router can autonomously decide on whether to accept a bundle (data) based on local information such as available storage and the value and risk of accepting the bundle (derived from historical statistics).

delay tolerant networking↗

NASA NTRS1990

Network, system, and status software enhancements for the autonomously managed electrical power system breadboard. Volume 3: Commands specification

This volume (3 of 4) contains the specification for the command language for the AMPS system. The volume contains a requirements specification for the operating system and commands and a design specification for the operating system and command. The operating system and commands sits on top of the protocol. The commands are an extension of the present set of AMPS commands in that the commands are more compact, allow multiple sub-commands to be bundled into one command, and have provisions for identifying the sender and the intended receiver. The commands make no change to the actual software that implement the commands.

Mckee, James W.↗

NASA NTRS2023

Application of Fountain Code to High-Rate Delay Tolerant Networks

Space communication poses several unique challenges that are not always present in typical terrestrial communications. Currently, communication with satellites is based on point-to-point links, and development of an interplanetary internet is an active research area. Delay Tolerant Networking (DTN) has been proposed as a way to mitigate the long delays and disruptions found in deep space. A specialized version of DTN, called High-rate Delay Tolerant Networking (HDTN), has been developed by NASA to support a variety of missions requiring store-and-forward capability. However, there are still several features that are desired for HDTN including data fragmentation, multicast, and anycast. This project proposes the application of fountain code in HDTN as a means of fragmenting, distributing, and reassembling data (in the form of bundles) across multiple nodes (i.e. satellites) to any number of receivers (i.e. ground stations). Fountain code is shown to be a promising encoding method for use with the HDTN protocol suite due to its short runtimes, small encoded file sizes, and loss tolerance.

Noah Douglass↗

NASA NTRS2011

Deep Space Networking Experiments on the EPOXI Spacecraft

NASA's Space Communications & Navigation Program within the Space Operations Directorate is operating a program to develop and deploy Disruption Tolerant Networking [DTN] technology for a wide variety of mission types by the end of 2011. DTN is an enabling element of the Interplanetary Internet where terrestrial networking protocols are generally unsuitable because they rely on timely and continuous end-to-end delivery of data and acknowledgments. In fall of 2008 and 2009 and 2011 the Jet Propulsion Laboratory installed and tested essential elements of DTN technology on the Deep Impact spacecraft. These experiments, called Deep Impact Network Experiment (DINET 1) were performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. The DINET 1 software was installed on the backup software partition on the backup flight computer for DINET 1. For DINET 1, the spacecraft was at a distance of about 15 million miles (24 million kilometers) from Earth. During DINET 1 300 images were transmitted from the JPL nodes to the spacecraft. Then, they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN's bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. The first DINET 1 experiment successfully validated many of the essential elements of the DTN protocols. DINET 2 demonstrated: 1) additional DTN functionality, 2) automated certain tasks which were manually implemented in DINET 1 and 3) installed the ION SW on nodes outside of JPL. DINET 3 plans to: 1) upgrade the LTP convergence-layer adapter to conform to the international LTP CL specification, 2) add convergence-layer "stewardship" procedures and 3) add the BSP security elements [PIB & PCB]. This paper describes the planning and execution of the flight experiment and the validation results.

automated data communication↗

DOE OSTI2026

ORCHID: Orchestrated Retrieval-Augmented Classification of High-Risk Property with Intelligent Decision-Making

High-Risk Property (HRP) classification is critical at U.S. Department of Energy (DOE) sites, where inventories include sensitive and often dual-use equipment. Compliance must track evolving rules designated by various export control policies to make transparent and auditable decisions. Traditional expert-only workflows are time-consuming, backlog-prone, and struggle to keep pace with shifting regulatory boundaries. We propose ORCHID, a modular agentic framework for HRP classification that pairs retrieval-augmented generation (RAG) with human oversight to produce policy based outputs that can be audited. Small cooperating agents—retrieval, description refiner, classifier, validator, and feedback logger—coordinate via agent-to-agent messaging and invoke tools through the Model Context Protocol (MCP) for model-agnostic on-premise operation. The interface follows an "Item to Evidence to Decision" loop with step-by-step reasoning, on-policy citations, and append-only audit bundles (run-cards, prompts, evidence). In preliminary tests on real HRP cases, ORCHID improves accuracy and traceability over a non-agentic baseline while deferring uncertain items to Subject Matter Experts (SMEs). The demonstration shows single item submission, grounded citations, SME feedback capture, and exportable audit artifacts—illustrating a practical path to trustworthy LLM assistance in sensitive DOE compliance workflows.

Das, Sanjay [ORNL] (ORCID:0009000542591915)↗

DOE OSTI2024

Mesh Computing Remote Automatic Workflow

The software suite uses a microservice architecture using Docker and `docker-compose`. The microservices are as follows: 1. User interface. This interface is written in JavaScript using the Svelte framework. It exposes form elements and a 3D visualizer to prompt the user through the definition of microstructure parameters, and setting parameters for mesh generation and refinement. 2. Mesh generator. This is a container running the Python package for DREAM3D to generate a voxelized mesh that represents a microstructure defined by the user in the interface. 3. Cubit runner. This is a secure shell protocol tool that makes the submitting the DREAM mesh to an HPC instance and starts to run Cubit shell commands to smooth the grain boundaries with its `sculpt` library, applies user-defined boundary node sets, and bundles and returns the simulation-ready meshes and input files as a zipped directory.

Harris, BrennanKay↗

NASA NTRS2007

Technical Issues in Implementing DTN in a Flight Software Architecture

This slide presentation reviews some of the technical issues in implementing Delay Tolerant Networking (DTN) in a enviornments that lack continuous network connectivity, such as spacecraft in deepspace or submarines. In a DTN, asynchronous variable-length messages (called bundles) are routed in a store and forward manner between participating nodes over a heterogeneous network. The review examines the enabling technologies, the porting steps and issues, operational scenarios for DTN. There is a review of the Licklider Transmission Protocol (LTP) aka Long-haul Transmission Protocol. Also included is a brief review of the current uses of DTN.

Licklider Transmission Protocol (LTP)↗

NASA NTRS2009

Distrubtion Tolerant Network Technology Flight Validation Report: DINET

In October and November of 2008, the Jet Propulsion Laboratory installed and tested essential elements of Delay/Disruption Tolerant Networking (DTN) technology on the Deep Impact spacecraft. This experiment, called Deep Impact Network Experiment (DINET), was performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. During DINET some 300 images were transmitted from the JPL nodes to the spacecraft. Then, they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN's bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. All transmitted bundles were successfully received, without corruption. The DINET experiment demonstrated DTN readiness for operational use in space missions.

networking↗

NASA NTRS2009

Distribution Tolerant Network Technology Flight Validation Report: DINET

In October and November of 2008, the Jet Propulsion Laboratory installed and tested essential elements of Delay/Disruption Tolerant Networking (DTN) technology on the Deep Impact spacecraft. This experiment, called Deep Impact Network Experiment (DINET), was performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. During DINET some 300 images were transmitted from the JPL nodes to the spacecraft. Then, they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN's bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. All transmitted bundles were successfully received, without corruption. The DINET experiment demonstrated DTN readiness for operational use in space missions.

networking↗

DOE OSTI2024

Zapiary: Creating Visibility in IOT Networks

Zigbee and Z-Wave are the main networking protocols used by low-power Internet of Things (IOT) devices. These protocols use low frequencies. Mesh architecture, and unique address formats that make them not compatible with traditional network traffic tools like IX-Discovery Tools. Zapiary is a software that takes CSV files with Zigbee and Z-Wave traffic and generates Structured Threat Information eXpression (STIX) JSON bundles illustrating the communication within IOT networks. The bundles can then be viewed within Structured Threat Intelligence Graph (STIG) or used with AI/ML models to provide deeper visibility into nodes that make up the network and the ability to trend the mesh network over time.

24 POWER TRANSMISSION AND DISTRIBUTION↗

NASA NTRS2002

Operating CFDP in the Interplanetary Internet

This paper examines the design elements of CCSDS File Delivery Protocol and Interplanetary Internet technologies that will simplify their integration and discusses the resulting new capabilities, such as efficient transmission of large files via multiple relay satellites operating in parallel.

CFDP IPN bundling↗

NASA NTRS2009

Disruption Tolerant Networking Flight Validation Experiment on NASA's EPOXI Mission

In October and November of 2008, the Jet Propulsion Laboratory installed and tested essential elements of Delay/Disruption Tolerant Networking (DTN) technology on the Deep Impact spacecraft. This experiment, called Deep Impact Network Experiment (DINET), was performed in close cooperation with the EPOXI project which has responsibility for the spacecraft. During DINET some 300 images were transmitted from the JPL nodes to the spacecraft. Then they were automatically forwarded from the spacecraft back to the JPL nodes, exercising DTN's bundle origination, transmission, acquisition, dynamic route computation, congestion control, prioritization, custody transfer, and automatic retransmission procedures, both on the spacecraft and on the ground, over a period of 27 days. All transmitted bundles were successfully received, without corruption. The DINET experiment demonstrated DTN readiness for operational use in space missions. This activity was part of a larger NASA space DTN development program to mature DTN to flight readiness for a wide variety of mission types by the end of 2011. This paper describes the DTN protocols, the flight demo implementation, validation metrics which were created for the experiment, and validation results.

DTN↗

NASA NTRS2012

BPTAP: A New Approach to IP over DTN

Traditional Internet protocols have been widely deployed for a variety of applications. However such protocols generally perform poorly in situations in which, round trip delays are very large (interplanetary distances) or . persistent connectivity is not always available (widely dispersed MANET). Delay/Disruption Tolerant Network (DTN) technology was invented to address these issues: (1) . Relay nodes "take custody" of blocks of network traffic on a hop-by -hop basis and retransmit them in cases of expected or unexpected link outage (2) Bundle lifetime may be configured for long round trip light times. BPTAP is novel by encapsulating Ethernet frames in BP

space links↗