Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “IP networks”

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.

At least 55 records · Page 3
All sourcesNASA NTRSDOE OSTI
NASA NTRS2002

Mobile Router Developed and Tested

The NASA Glenn Research Center, under a NASA Space Act Agreement with Cisco Systems, has been performing joint networking research to apply Internet-based technologies and protocols to space-based communications. As a result of this research, NASA performed stringent performance testing of the mobile router, including the interaction of routing and the transport-level protocol. In addition, Cisco Systems developed the mobile router for both commercial and Government markets. The code has become part of the Cisco Systems Internetworking Operating System (IOS) as of release 12.2 (4) T--which will make this capability available to the community at large. The mobile router is software code that resides in a network router and enables entire networks to roam while maintaining connectivity to the Internet. This router code is pertinent to a myriad of applications for both Government and commercial sectors, including the "wireless battlefield." NASA and the Department of Defense will utilize this technology for near-planetary observation and sensing spacecraft. It is also a key enabling technology for aviation-based information applications. Mobile routing will make it possible for information such as weather, air traffic control, voice, and video to be transmitted to aircraft using Internet-based protocols. This technology shows great promise in reducing congested airways and mitigating aviation disasters due to bad weather. The mobile router can also be incorporated into emergency vehicles (such as ambulances and life-flight aircraft) to provide real-time connectivity back to the hospital and health-care experts, enabling the timely application of emergency care. Commercial applications include entertainment services, Internet protocol (IP) telephone, and Internet connectivity for cruise ships, commercial shipping, tour buses, aircraft, and eventually cars. A mobile router, which is based on mobile IP, allows hosts (mobile nodes) to seamlessly "roam" among various IP subnetworks. This is essential in many wireless networks. A mobile router, unlike a mobile IP node, allows entire networks to roam. Hence, a device connected to the mobile router does not need to be a mobile node because the mobile router provides the roaming capabilities. There are three basic elements in the mobile IP: the home agent, the foreign agent, and the mobile node. The home agent is a router on a mobile node's home network that tunnels datagrams for delivery to the mobile node when it is away from home. The foreign agent is a router on a remote network that provides routing services to a registered mobile node. The mobile node is a host or router that changes its point of attachment from one network or subnetwork to another. In mobile routing, virtual communications are maintained by the home agent, which forwards all packets for the mobile networks to the foreign agent. The foreign agent passes the packets to the mobile router, which then forwards the packets to the devices on its networks. As the mobile router moves, it will register with its home agent on its whereabouts via the foreign agent to assure continuous connectivity.

Ivancic, William D.↗
NASA NTRS2002

Ethernet for Space Flight Applications

NASA's Goddard Space Flight Center (GSFC) is adapting current data networking technologies to fly on future spaceflight missions. The benefits of using commercially based networking standards and protocols have been widely discussed and are expected to include reduction in overall mission cost, shortened integration and test (I&T) schedules, increased operations flexibility, and hardware and software upgradeability/scalability with developments ongoing in the commercial world. The networking effort is a comprehensive one encompassing missions ranging from small University Explorer (UNEX) class spacecraft to large observatories such as the Next Generation Space Telescope (NGST). Mission aspects such as flight hardware and software, ground station hardware and software, operations, RF communications, and security (physical and electronic) are all being addressed to ensure a complete end-to-end system solution. One of the current networking development efforts at GSFC is the SpaceLAN (Spacecraft Local Area Network) project, development of a space-qualifiable Ethernet network. To this end we have purchased an IEEE 802.3-compatible 10/100/1000 Media Access Control (MAC) layer Intellectual Property (IP) core and are designing a network node interface (NNI) and associated network components such as a switch. These systems will ultimately allow the replacement of the typical MIL-STD-1553/1773 and custom interfaces that inhabit most spacecraft. In this paper we will describe our current Ethernet NNI development along with a novel new space qualified physical layer that will be used in place of the standard interfaces. We will outline our plans for development of space qualified network components that will allow future spacecraft to operate in significant radiation environments while using a single onboard network for reliable commanding and data transfer. There will be a brief discussion of some issues surrounding system implications of a flight Ethernet. Finally, we will show an onboard network architecture for a proposed new mission using Ethernet for science data transport.

Webb, Evan↗
NASA NTRSDate not supplied

A Proposed Clock Synchronization Method for the Solar System Internet

Networked communications in space are necessary to achieve scalability in terms of the number of communicating nodes but also in terms of the overall system complexity. A key component to such a system is the ability to synchronize clocks, which is the focus of this paper. The so-called Solar System Internet (SSI) will be built upon Delay Tolerant Networking (DTN), which, in analogy to the Internet Protocol (IP), can be considered a suite of protocols necessary for networking in the space domain. Therefore, our goal is to extend this suite to include a DTN clock synchronization capability, analogous to the Network Time Protocol (NTP) used in the Internet. A motivating example of a network in space is NASA’s LunaNet, a vision for a multi-hop multi-path network extending to the moon wherein not all nodes will have direct connections to an authoritative reference clock. In this paper, we propose a general clock synchronization methodology and algorithm that could be used for LunaNet as well as more elaborate time-varying networks. In recent years, DTN has benefited from modeling efforts founded on the mathematical tool of sheaves. Here we continue this work to provide an approach to clock synchronization. Due to the time-varying nature of space networks, absolute consensus is not possible. However, the sheaf Laplacian provides a practical, distributed approach to approximating consensus by allowing data to diffuse through the network. In particular, the sheaf Laplacian is readily computable, lending our approach to implementation. Our approach is well suited to handle the difficulties of space networks. For instance, differences in clock accuracy mean certain nodes are more authoritative than others; we can account for these differences through hierarchies in the network, generalizing the strata in NTP. Furthermore, just as error estimation is an integral part of NTP, we are able to give concrete error bounds for our approach. Indeed, different applications (e.g., communications schedules, pointing, navigation, distributed science) will have different requirements, hence it is necessary to maintain clocks within a given tolerance. We outline some of the necessary steps to turn our approach into a practical network protocol that could be used in DTN, and we conclude the paper with suggestions for future research.

Michael Moy↗
NASA NTRS1991

Development of ISO connection-oriented/correctionless gateways

The project had two goals, establishment of a gateway between French and U.S. academic networks and studies of issues related to the development of ISO connection-oriented/connectionless (CO/CL) gateways. The first component involved installation of a 56K bps line between Princeton Univ. and INRIA in France. The end-points of these lines were connected by Vitalink link level bridges. The Princeton end was then connected to the NSFNET via the John Von Neumann Supercomputer Center. The French end was connected to Transpac, the French X.25 public data network and to the French IP research internet. U.S. users may communicate with users of the French internet by e-mail and may access computational and data resources in France by use of remote login and file transfer. The connection to Transpac enables U.S. users to access the SIMBAD astronomical database outside of Paris. Access to this database from the U.S. can be via TCP/IP or DECNET (via a DECNET to TCP/IP gateway) protocols utilizing a TCP/IP to X.25 gateway developed and operated by INRIA. The second component of the project involved experiments aimed at understanding the issues involved is ISO CO/CL gateways. An experimental gateway was developed at Wisconsin and a preliminary report was prepared. Because of the need to devote most resources to the first component of the project, work in this area did not go beyond development of a prototype gateway.

Landweber, Lawrence H.↗
NASA NTRS2005

Location Management in a Transport Layer Mobility Architecture

Mobility architectures that place complexity in end nodes rather than in the network interior have many advantageous properties and are becoming popular research topics. Such architectures typically push mobility support into higher layers of the protocol stack than network layer approaches like Mobile IP. The literature is ripe with proposals to provide mobility services in the transport, session, and application layers. In this paper, we focus on a mobility architecture that makes the most significant changes to the transport layer. A common problem amongst all mobility protocols at various layers is location management, which entails translating some form of static identifier into a mobile node's dynamic location. Location management is required for mobile nodes to be able to provide globally-reachable services on-demand to other hosts. In this paper, we describe the challenges of location management in a transport layer mobility architecture, and discuss the advantages and disadvantages of various solutions proposed in the literature. Our conclusion is that, in principle, secure dynamic DNS is most desirable, although it may have current operational limitations. We note that this topic has room for further exploration, and we present this paper largely as a starting point for comparing possible solutions.

Eddy, Wesley M.↗
NASA NTRS2017

Considerations for an Integrated UAS CNS Architecture

The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) is investigating revolutionary and advanced universal, reliable, always available, cyber secure and affordable Communication, Navigation, Surveillance (CNS) options for all altitudes of UAS operations. In Spring 2015, NASA issued a Call for Proposals under NASA Research Announcements (NRA) NNH15ZEA001N, Amendment 7 Subtopic 2.4. Boeing was selected to conduct a study with the objective to determine the most promising candidate technologies for Unmanned Air Systems (UAS) air-to-air and air-to-ground data exchange and analyze their suitability in a post-NextGen NAS environment. The overall objectives are to develop UAS CNS requirements and then develop architectures that satisfy the requirements for UAS in both controlled and uncontrolled air space. This contract is funded under NASAs Aeronautics Research Mission Directorates (ARMD) Aviation Operations and Safety Program (AOSP) Safe Autonomous Systems Operations (SASO) project and proposes technologies for the Unmanned Air Systems Traffic Management (UTM) service.There is a need for accommodating large-scale populations of Unmanned Air Systems (UAS) in the national air space. Scale obviously impacts capacity planning for Communication, Navitation, and Surveillance (CNS) technologies. For example, can wireless communications data links provide the necessary capacity for accommodating millions of small UASs (sUAS) nationwide? Does the communications network provide sufficient Internet Protocol (IP) address space to allow air traffic control to securely address both UAS teams as a whole as well as individual UAS within each team? Can navigation and surveillance approaches assure safe route planning and safe separation of vehicles even in crowded skies?Our objective is to identify revolutionary and advanced CNS alternatives supporting UASs operating at all altitudes and in all airspace while accurately navigating in the absence of navigational aids. These CNS alternatives must be reliable, redundant, always available, cyber-secure, and affordable for all types of vehicles including small UAS to large transport category aircraft. The approach will identify CNS technology candidates that can meet the needs of the range of UAS missions to specific air traffic management applications where they will be most beneficial and cost effective.

Templin, Fred L.↗
NASA NTRS2017

Considerations for an Integrated UAS CNS Architecture

The National Aeronautics and Space Administration (NASA) Glenn Research Center (GRC) is investigating revolutionary and advanced universal, reliable, always available, cyber secure and affordable Communication, Navigation, Surveillance (CNS) options for all altitudes of UAS operations. In Spring 2015, NASA issued a Call for Proposals under NASA Research Announcements (NRA) NNH15ZEA001N, Amendment 7 Subtopic 2.4. Boeing was selected to conduct a study with the objective to determine the most promising candidate technologies for Unmanned Air Systems (UAS) air-to-air and air-to-ground data exchange and analyze their suitability in a post-NextGen NAS environment. The overall objectives are to develop UAS CNS requirements and then develop architectures that satisfy the requirements for UAS in both controlled and uncontrolled air space. This contract is funded under NASAs Aeronautics Research Mission Directorates (ARMD) Aviation Operations and Safety Program (AOSP) Safe Autonomous Systems Operations (SASO) project and proposes technologies for the Unmanned Air Systems Traffic Management (UTM) service.There is a need for accommodating large-scale populations of Unmanned Air Systems (UAS) in the national air space. Scale obviously impacts capacity planning for Communication, Navigation, and Surveillance (CNS) technologies. For example, can wireless communications data links provide the necessary capacity for accommodating millions of small UASs (sUAS) nationwide? Does the communications network provide sufficient Internet Protocol (IP) address space to allow air traffic control to securely address both UAS teams as a whole as well as individual UAS within each team? Can navigation and surveillance approaches assure safe route planning and safe separation of vehicles even in crowded skies?Our objective is to identify revolutionary and advanced CNS alternatives supporting UASs operating at all altitudes and in all airspace while accurately navigating in the absence of navigational aids. These CNS alternatives must be reliable, redundant, always available, cyber-secure, and affordable for all types of vehicles including small UAS to large transport category aircraft. The approach will identify CNS technology candidates that can meet the needs of the range of UAS missions to specific air traffic management applications where they will be most beneficial and cost effective.

Templin, Fred L.↗
NASA NTRS2018

Reliable and Secure Surveillance, Communications and Navigation (RSCAN) for Unmanned Air Systems (UAS) in Controlled Airspace

The aviation industry faces a rapidly-emerging need for integrating Unmanned Air Systems (UAS) into the national airspace (NAS). This trend will present challenging questions for the safe operation of UAS in controlled and uncontrolled airspaces based on new Communications, Navigation and Surveillance (CNS) technologies. For example, can wireless communications data links provide the necessary capacity for accommodating ever increasing numbers of UAS worldwide? Does the communications network provide ample Internet Protocol (IP) address space to allow Air Traffic Control (ATC) to securely address each UAS? Can navigation and surveillance approaches assure safe route planning and safe separation of vehicles even in crowded skies?Under NASA contract NNA16BD84C, Boeing is developing an integrated CNS architecture to enable UAS operations in the NAS. Revolutionary and advanced CNS alternatives are needed to support UAS operations at all altitudes and in all airspaces, including both controlled and uncontrolled. These CNS alternatives must be reliable, redundant, always available, cyber-secure, and affordable for all types of vehicles including small UAS to large transport category aircraft. Our approach considers CNS requirements that address the range of UAS missions where they will be most beneficial and cost-effective.A cybersecure future UAS CNS architecture is needed to support the NASA vision for an Unmanned Air Traffic Management (UTM) system in uncontrolled airspace and a cooperative operation of manned and unmanned aircraft in the controlled global Air Traffic Management (ATM) system. The architecture must, therefore, support always-available and cyber secure operations. This paper presents UAS CNS architecture concepts for large UAS operating in the ATM system in controlled airspace. Future companion works will consider small UAS operating in the UTM system in uncontrolled airspace.

Ponchak, Denise S.↗
NASA NTRS1997

Study and Simulation of Enhancements for TCP (Transmission Control Protocol) Performance Over Noisy, High-Latency Links

The designers of the TCP/IP protocol suite explicitly included support of satellites in their design goals. The goal of the Internet Project was to design a protocol which could be layered over different networking technologies to allow them to be concatenated into an internet. The results of this project included two protocols, IP and TCP. IP is the protocol used by all elements in the network and it defines the standard packet format for IP datagrams. TCP is the end-to-end transport protocol commonly used between end systems on the Internet to derive a reliable bi-directional byte-pipe service from the underlying unreliable IP datagram service. Satellite links are explicitly mentioned in Vint Cerf's 2-page article which appeared in 1980 in CCR [2] to introduce the specifications for IP and TCP. In the past fifteen years, TCP has been demonstrated to work over many differing networking technologies, including over paths including satellites links. So if satellite links were in the minds of the designers from the beginning, what is the problem? The problem is that the performance of TCP has in some cases been disappointing. A goal of the authors of the original specification of TCP was to specify only enough behavior to ensure interoperability. The specification left a number of important decisions, in particular how much data is to be sent when, to the implementor. This was deliberately' done. By leaving performance-related decisions to the implementor, this would allow the protocol TCP to be tuned and adapted to different networks and situations in the future without the need to revise the specification of the protocol, or break interoperability. Interoperability would continue while future implementations would be allowed flexibility to adapt to needs which could not be anticipated at the time of the original protocol design.

Shepard, Timothy J.↗
NASA NTRS2000

FTP Extensions for Variable Protocol Specification

The specification for the File Transfer Protocol (FTP) assumes that the underlying network protocols use a 32-bit network address and a 16-bit transport address (specifically IP version 4 and TCP). With the deployment of version 6 of the Internet Protocol, network addresses will no longer be 32-bits. This paper species extensions to FTP that will allow the protocol to work over a variety of network and transport protocols.

Allman, Mark↗
NASA NTRS2006

A Space Operations Network Alternative: Using Globally Connected Research and Education Networks for Space-Based Science Operations

Earth based networking in support of various space agency projects has been based on leased service/circuits which has a high associated cost. This cost is almost always taken from the science side resulting in less science. This is a proposal to use Research and Education Networks (RENs) worldwide to support space flight operations in general and space-based science operations in particular. The RENs were developed to support scientific and educational endeavors. They do not provide support for general Internet traffic. The connectivity and performance of the research and education networks is superb. The connectivity at Layer 3 (IP) virtually encompasses the globe. Most third world countries and all developed countries have their own research and education networks, which are connected globally. Performance of the RENs especially in the developed countries is exceptional. Bandwidth capacity currently exists and future expansion promises that this capacity will continue. REN performance statistics has always exceeded minimum requirements for spaceflight support. Research and Education networks are more loosely managed than a corporate network but are highly managed when compared to the commodity Internet. Management of RENs on an international level is accomplished by the International Network Operations Center at Indiana University at Indianapolis. With few exceptions, each regional and national REN has its own network ops center. The acceptable use policies (AUP), although differing by country, allows any scientific program or project the use of their networks. Once in compliance with the first RENs AUP, all others will accept that specific traffic including regional and transoceanic networks. RENs can support spaceflight related scientific programs and projects. Getting the science to the researcher is obviously key to any scientific project. RENs provide a pathway to virtually any college or university in the world, as well as many governmental institutes and science centers. RENs are not to be used for mission critical types of network traffic, even though RENs performance characteristics would support it.

Bradford, Robert N.↗
NASA NTRS2010

Large File Transfers from Space Using Multiple Ground Terminals and Delay-Tolerant Networking

We use Delay-Tolerant Networking (DTN) to break control loops between space-ground communication links and ground-ground communication links to increase overall file delivery efficiency, as well as to enable large files to be proactively fragmented and received across multiple ground stations. DTN proactive fragmentation and reactive fragmentation were demonstrated from the UK-DMC satellite using two independent ground stations. The files were reassembled at a bundle agent, located at Glenn Research Center in Cleveland Ohio. The first space-based demonstration of this occurred on September 30 and October 1, 2009. This paper details those experiments. Communication, delay-tolerant networking, DTN, satellite, Internet, protocols, bundle, IP, TCP.

Ivancic, William D.↗
NASA NTRS1996

Gigabit Satellite Network for NASA's Advanced Communication Technology Satellite (ACTS)

The advanced communication technology satellite (ACTS) gigabit satellite network provides long-haul point-to-point and point-to-multipoint full-duplex SONET services over NASA's ACTS. at rates up to 622 Mbit/s (SONET OC-12), with signal quality comparable to that obtained with terrestrial fiber networks. Data multiplexing over the satellite is accomplished using time-division multiple access (TDMA) techniques coordinated with the switching and beam hopping facilities provided by ACTS. Transmissions through the satellite are protected with Reed-Solomon encoding. providing virtually error-free transmission under most weather conditions. Unique to the system are a TDMA frame structure and satellite synchronization mechanism that allow: (a) very efficient utilization of the satellite capacity: (b) over-the-satellite dosed-loop synchronization of the network in configurations with up to 64 ground stations: and (c) ground station initial acquisition without collisions with existing signalling or data traffic. The user interfaces are compatible with SONET standards, performing the function of conventional SONET multiplexers and. as such. can be: readily integrated with standard SONET fiber-based terrestrial networks. Management of the network is based upon the simple network management protocol (SNMP). and includes an over-the-satellite signalling network and backup terrestrial internet (IP-based) connectivity. A description of the ground stations is also included.

Hoder, Douglas↗
NASA NTRS2019

Evaluation of Classifier Complexity for Delay Tolerant Network Routing

The growing popularity of small cost effective satellites (SmallSats, CubeSats, etc.) creates the potential for a variety of new science applications involving multiple nodes functioning together or independently to achieve a task, such as swarms and constellations. As this technology develops and is deployed for missions in Low Earth Orbit and beyond, the use of delay tolerant networking (DTN) techniques may improve communication capabilities within the network. In this paper, a network hierarchy is developed from heterogeneous networks of SmallSats, surface vehicles, relay satellites and ground stations which form an integrated network. There is a tradeoff between complexity, flexibility, and scalability of user defined schedules versus autonomous routing as the number of nodes in the network increases. To address these issues, this work proposes a machine learning classifier based on DTN routing metrics. A framework is developed which will allow for the use of several categories of machine learning algorithms (decision tree, random forest and deep learning) to be applied to a dataset of historical network statistics, which allows for the evaluation of algorithm complexity versus performance to be explored. We develop the emulation of a hierarchical network, consisting of tens of nodes which form a cognitive network architecture. CORE (Common Open Research Emulator) is used to emulate the network using bundle protocol and DTN IP neighbor discovery.

Dudukovich, Rachel↗
NASA NTRS2000

COTS-Based Fault Tolerance in Deep Space: Qualitative and Quantitative Analyses of a Bus Network Architecture

Using COTS products, standards and intellectual properties (IPs) for all the system and component interfaces is a crucial step toward significant reduction of both system cost and development cost as the COTS interfaces enable other COTS products and IPs to be readily accommodated by the target system architecture. With respect to the long-term survivable systems for deep-space missions, the major challenge for us is, under stringent power and mass constraints, to achieve ultra-high reliability of the system comprising COTS products and standards that are not developed for mission-critical applications. The spirit of our solution is to exploit the pertinent standard features of a COTS product to circumvent its shortcomings, though these standard features may not be originally designed for highly reliable systems. In this paper, we discuss our experiences and findings on the design of an IEEE 1394 compliant fault-tolerant COTS-based bus architecture. We first derive and qualitatively analyze a -'stacktree topology" that not only complies with IEEE 1394 but also enables the implementation of a fault-tolerant bus architecture without node redundancy. We then present a quantitative evaluation that demonstrates significant reliability improvement from the COTS-based fault tolerance.

Tai, Ann T.↗
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 NTRS2010

Enabling IP Header Compression in COTS Routers via Frame Relay on a Simplex Link

NASA is moving toward a networkcentric communications architecture and, in particular, is building toward use of Internet Protocol (IP) in space. The use of IP is motivated by its ubiquitous application in many communications networks and in available commercial off-the-shelf (COTS) technology. The Constellation Program intends to fit two or more voice (over IP) channels on both the forward link to, and the return link from, the Orion Crew Exploration Vehicle (CEV) during all mission phases. Efficient bandwidth utilization of the links is key for voice applications. In Voice over IP (VoIP), the IP packets are limited to small sizes to keep voice latency at a minimum. The common voice codec used in VoIP is G.729. This new algorithm produces voice audio at 8 kbps and in packets of 10-milliseconds duration. Constellation has designed the VoIP communications stack to use the combination of IP/UDP/RTP protocols where IP carries a 20-byte header, UDP (User Datagram Protocol) carries an 8-byte header, and RTP (Real Time Transport Protocol) carries a 12-byte header. The protocol headers total 40 bytes and are equal in length to a 40-byte G.729 payload, doubling the VoIP latency. Since much of the IP/UDP/RTP header information does not change from IP packet to IP packet, IP/UDP/RTP header compression can avoid transmission of much redundant data as well as reduce VoIP latency. The benefits of IP header compression are more pronounced at low data rate links such as the forward and return links during CEV launch. IP/UDP/RTP header compression codecs are well supported by many COTS routers. A common interface to the COTS routers is through frame relay. However, enabling IP header compression over frame relay, according to industry standard (Frame Relay IP Header Compression Agreement FRF.20), requires a duplex link and negotiations between the compressor router and the decompressor router. In Constellation, each forward to and return link from the CEV in space is treated independently as a simplex link. Without negotiation, the COTS routers are prevented from entering into the IP header compression mode, and no IP header compression would be performed. An algorithm is proposed to enable IP header compression in COTS routers on a simplex link with no negotiation or with a one-way messaging. In doing so, COTS routers can enter IP header compression mode without the need to handshake through a bidirectional link as required by FRF.20. This technique would spoof the routers locally and thereby allow the routers to enter into IP header compression mode without having the negotiations between routers actually occur. The spoofing function is conducted by a frame relay adapter (also COTS) with the capability to generate control messages according to the FRF.20 descriptions. Therefore, negotiation is actually performed between the FRF.20 adapter and the connecting COTS router locally and never occurs over the space link. Through understanding of the handshaking protocol described by FRF.20, the necessary FRF.20 negotiations messages can be generated to control the connecting router, not only to turn on IP header compression but also to adjust the compression parameters. The FRF.20 negotiation (or control) message is composed in the FRF.20 adapter by interpreting the incoming router request message. Many of the fields are simply transcribed from request to response while the control field indicating response and type are modified.

Nguyen, Sam P.↗