SDA-SN-20-0002 (Space Mesh Networking).pdf

Space Development Agency

Space Mesh Networking Capabilities and Interoperability

Request for Information

SDA-SN-20-0002

The Space Development Agency (SDA) is seeking industry feedback on in-space mesh networking capabilities and interoperability to inform SDA’s future solicitations, including the Transport Tranche 0 solicitation anticipated for Spring 2020.

Background

The National Defense Strategy (NDS) acknowledges that space is vital to the U.S. way of life, our national security, and modern warfare. In an era of renewed great power competition, maintaining our advantage in space is critical to winning these long-term strategic competitions.

Potential adversaries seek to undermine this goal by employing strategies that exploit real or perceived vulnerabilities in our current and planned National Security Space systems. In addition, these potential adversaries are developing and demonstrating multi-domain threats to national security much faster than we can deploy responsive space-based capabilities. The Department of Defense (DoD) established SDA on 12 March 2019 as a separate Defense Agency under the control, direction, and authority of the Under Secretary of Defense for Research and Engineering (USD(R&E)) as a response to this problem.

SDA is responsible for defining and monitoring the Department's future threat-driven space architecture and accelerating the development and fielding of new military space capabilities necessary to ensure our technological and military advantage in space for national defense. To achieve this mission, SDA will unify and integrate next-generation space capabilities to deliver the National Defense Space Architecture (NDSA), a resilient military sensing and data transport capability via a proliferated space architecture primarily in Low Earth Orbit (LEO). SDA will not necessarily develop and field all capabilities of the NDSA but rather orchestrate those efforts across DoD and fill in gaps in capabilities while providing the integrated architecture.

Initially the NDSA is comprised of the following layers, addressing the critical priorities for space identified within the DoD Space Vision:

- Transport Layer, to provide assured, resilient, low-latency military data and connectivity worldwide to the full range of warfighter platforms;

- Battle Management Layer, to provide architecture tasking, mission command and control, and data dissemination to support time-sensitive kill chain closure at campaign scales;

- Tracking Layer, to provide global indications, warning, tracking, and targeting of advanced missile threats, including hypersonic missile systems;

- Custody Layer, to provide 24x7, all-weather custody of time-sensitive, left-of-launch surface mobile targets (e.g., to support targeting for advanced missiles);

- Navigation Layer, to provide alternate position, navigation, and timing (A-PNT) for GPS-denied environments;

- Deterrence Layer, to deter hostile action in deep space (beyond Geosynchronous Earth Orbit (GEO) up to lunar distances);

- Support Layer, to enable ground and launch segments to support a responsive space architecture.

SDA's mission begins and ends with the warfighter. SDA recognizes that sufficient or "good enough" capabilities in the hands of warfighter sooner may be better than delivering the perfect solution too late. SDA will deliver capabilities to our joint warfighting forces in two-year tranches.

Tranche 0, or the warfighter immersion tranche, will be delivered as early as Fiscal Year (FY) 2022 and consists of tens of satellites providing periodic, regional sensing and data transport capabilities, including the capability to detect hypersonic glide vehicles and to disseminate time-sensitive targeting solutions over tactical data links. SDA anticipates issuing separate solicitations for each of the capability layers in each tranche. For Tranche 0, SDA anticipates issuing the Transport Layer solicitation in Spring 2020, followed closely by other solicitations through Summer 2020.

SDA Notional Transport Layer Architecture

While the SDA’s Transport Layer objective architecture has not been finalized and the trade space is still being evaluated, two candidate architectures are being simulated to better understand networking requirements.

The first candidate architecture consists of a 400-satellite constellation at 750km altitude. Three hundred of these satellites will consist of a Walker constellation of 15 planes inclined at 55 degrees. The additional 100 satellites consist of a Walker constellation of 5 planes inclined at 82 degrees.

The second Transport Layer candidate architecture which has been simulated consists of a 270-satellite constellation at 1200km. Two hundred and ten of these satellites comprise a Walker constellation of 14 planes inclined at 55 degrees. The remaining 60 satellites form a Walker constellation of 4 planes inclined at 82 degrees.

In all architecture situations, in-space mesh networks (henceforth, referred to as networks or networking) are critical to the Transport Layer. The Consultative Committee for Space Data Systems (CCSDS)’s significant efforts in establishing open standards has laid the foundation towards the establishment of open standards within the community. But it has become apparent that new networking protocols will have to be developed or adopted from industry in order to make the SDA constellation a success.

The OSI reference model itself however is not an implementation specification, yet efforts like the Consultative Committee for Space Data Systems (CCSDS) help establish more definitive standards for commercial developers to ensure interoperability within space systems.

SDA’s approach to architecting and building out a proliferated LEO constellation is to select at least two vendors. SDA not only wants to leverage the commercial sector’s approach to commoditized buses, but the SDA believes that to reduce risk associated with the commercial sector it is necessary to award to more than one vendor. This poses a significant risk with respect to interoperability of space networks. Hence network interoperability is critical to building out the SDA proliferated LEO constellation. It is a standing SDA requirement for each vendor’s Transport layer satellites to be interoperable with a standardized space mesh network.

Space Mesh Networks

The SDA expects that its proliferated LEO constellations will leverage the Open Systems Interconnection (OSI) reference model, and the system functionality may be divided into seven distinct groups of related functions. All nodes within the SDA architecture (Transport or contributing space-based sensing capabilities such as the SDA Tracking Layer) will use these seven functionalities to communicate and maintain satellite operations. The OSI reference model itself however is not an implementation specification, yet efforts like the Consultative Committee for Space Data Systems (CCSDS) help establish more definitive standards for commercial developers to ensure interoperability within space systems.

The commercial sector has employed the CCSDS’ published standards to provide higher fidelity to the OSI model to help vendors achieve some level of interoperability. Among these are:

Proximity-1 Space Link Protocol--Physical Layer (CCSDS 211.1-B-4), Proximity-1 Space Link Protocol - Data Link Layer (CCSDS 211.0-B-5), Proximity-1 Space Link Protocol – Coding and Synchronization Sublayer (CCSDS 211.2-B-3), Space Packet Protocol (CCSDS 133.0-B-1), the Encapsulation Service (CCSDS 133.1-B-2) as well as others.

The Internet Engineering Task Force (IETF) is actively developing MANET standards for bidirectional, event-driven communication between the router and the modem to handle dynamic link characteristics such as Optimized Link State Routing Protocol Version 2 (RFC 7181) and Dynamic Link Exchange Protocol (DLEP) (RFC 8175, RFC 8629 and RFC 8651). In addition, the IETF and CCSDS are developing standards for Delay/Disruption Tolerant Networking (DTN) that will operate with resilience over MANET-like networks and assure data delivery in spite of losing links. The existing Bundle Protocol version 6 is being replaced by version 7 (draft-ietf-dtn-bpbis-19) while being extended to address security (draft-ietf-dtn-bpsec- 16, Bundle Protocol Security Specification, and CCSDS 734x5r1, Streamlined Bundle Security Protocol Specification), integration with transport control (draft-ietf-dtn-tcpclv4-17, Delay- Tolerant Networking TCP Convergence Layer Protocol Version 4), and addition of streaming voice and video services (CCSDS 766x3r1, Specification for RTP as Transport for Audio and Video over DTN). Since the SDA will be reliant on more than one vendor for its P-LEO constellation, it is critical that networking open standards be defined with a level of fidelity to ensure interoperability.

Additionally, there are attributes which have yet to be defined for large constellations: physical topologies, transport (multi or single network), routing protocols, full or partial mesh networking (e.g. dynamic, local networks within the global network). SDA recognizes that as its constellation nodes increase, a flexible and dynamically distributed architecture will be required to work together in an integrated information system to support Transport/Tracking/Custody scenarios. SDA is also aware of the commercial sector’s research into dynamically changing topologies and interrogation-based relay routing mechanisms (e.g. interrogation-based routing with buffers).

https://public.ccsds.org/Pubs/211x1b4e1.pdf https://public.ccsds.org/Pubs/211x0b5.pdf https://public.ccsds.org/Pubs/211x2b3.pdf https://public.ccsds.org/Pubs/133x0b1c2.pdf https://public.ccsds.org/Pubs/133x1b2c2.pdf https://datatracker.ietf.org/doc/rfc7181/ https://datatracker.ietf.org/doc/rfc7181/ https://datatracker.ietf.org/doc/rfc8175/ https://datatracker.ietf.org/doc/rfc8629/ https://datatracker.ietf.org/doc/rfc8651/ https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/ https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/ https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec/ https://public.ccsds.org/Lists/CCSDS%207345R1/734x5r1.pdf https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/ https://public.ccsds.org/Lists/CCSDS%207663R1/766x3r1.pdf

However, there is still much work that is needed to accommodate the anticipated satellite densities, orbital dynamics, traffic engineering parameters, service and network management, and desired network behaviors.

Fundamentally, the SDA transport space mesh network behaves differently from traditional MANET in the following aspects:

- Traditional MANET protocols start with no a priori knowledge about neighbors, since the entire network is discovered and formed in an opportunistic manner. For the NDSA, the network node positions are known in advance to some degree of confidence through state and state uncertainty estimation, propagation, and dissemination. In addition, the Optical Inter-Satellite Links (OISL) support intersatellite ranging and time transfer.

- MANET is designed to support a wide range of network densities from sparse (very few neighbors) to dense (many neighbors). The above SDA candidate architectures suggest neither extreme may be applicable.

- Traditional MANET protocols are not designed for active adversary anti-access/area denial (A2/AD) environments. Military MANETs may require balanced use of preformed/planned network topology for rapid deployment and ad hoc, real-time modification of network topology under battlefield conditions.

In future tranches, SDA’s Transport Layer will need to interoperate with tactical airborne and other networks. This may require modifications or extensions to MANET capabilities for interoperation with networks using dissimilar service and network management approaches.

Consequently, traditional MANET protocol overhead where the entire network is continuously performing neighborhood self-discovery, self-joining, and self-healing operations may not be optimal for the low-latency Transport Layer. In addition, the Transport Layer network physical topology may be predicted beforehand in most cases, resulting in initial routing paths that can be calculated and disseminated in advance.

However, it is important that the autonomous SDA transport space mesh network can respond to situations when parts of the network are not available due to equipment malfunctions, adversarial attacks, or resource exhaustion. Under these circumstances, the network will need to be resilient when network connectivity is in a degraded state. Notionally, the SDA network may function in these two modes:

- Normal Mode: This is when the network is functioning normally without any outages. In this mode, the network may use a standard routing protocol or pre-calculated route.

- Recovery Mode: This is when portion of the network is degraded or not operational due to malfunctions or adversarial attacks. In this case the network must be able to detect the outage, recover and heal itself using the remaining network elements.

SDA’s Request for Information (RFI)

SDA is specifically seeking the following information to inform future solicitations and reduce risk toward networking interoperability within the SDA architecture and development plans. Industry feedback on critical elements of a networking open standard (as highlighted below):

1. Industry feedback on additional standards which would complement CCSDS standards already documented (as highlighted below).

2. Industry feedback on different approaches to, and complexity of, networking and the maturity or readiness of those approaches today through FY2024. What is the path of mesh networking evolutionary development?

3. Statement of vendor’s capabilities in area of in-space mesh networking.

SDA is aware that there has been significant development in the commercial sector in the application of the OSI reference model to space mesh networking. While the CCSDS and IETF have released several technical networking specifications, higher fidelity standards are necessary to ensure interoperability between vendors. While some commercial approaches have been successful in the development of proliferated constellation network, there are still considerable technical issues which need to be addressed beyond networking specifications.

Specifically, SDA is seeking industry input into the following technologies with respect to space mesh networking:

Network interoperability

Novel resilient routing and reliable, low-latency transport protocols/methods

Network control plane and management solutions

System performance monitoring

Fault detection and correction mechanisms

Efficient Central Processing Unit (CPU) utilization

Packet loss, latency, and delay variation mitigation techniques

Handshake protocol from user to user (and vendor to vendor)

P-LEO network neighbor peering and approaches (vendor-agnostic interoperability)

Software updates (especially software updates during data delivery)

Congestion-aware routing

Quality of Service (QoS)

System-wide distribution of almanac (especially ephemeris), e.g., DTN contact graph routing

End-to-End confidentiality and integrity techniques

End-to-end Cyber Security

Network information discovery

Media access control

Open architecture systems

OSI transport protocol throughput optimization for TCP/UDP over space mesh network

Network scalability (e.g. protocol overhead vs. user throughput, vs. constellation size)

Application of machine learning to space networking

Predictive routing for satellite systems

Buffer design and integration with network protocols

Typical commercial traffic loads

Resilience to active A2/AD strategies

To provide additional context to the networking technologies highlighted above, the following statements provide a baseline from which SDA seeks feedback on industry research, development, and employment:

Network Routing Strategies

Identification of specific data link, network, and transport layer routing protocol standards or algorithms for dynamic network topologies including their risks and maturity, technology readiness levels, and critical components or software that may need to be developed and demonstrated in advance of a proliferated constellation procurement

Approaches to ensure network scalability with respect to traffic throughput, network control overhead, and node elements

Approaches to interoperation with adjacent networks using dissimilar service and network management protocols

Identification of applicable Quality of Service mechanisms for ad hoc, dynamic, high-throughput networks

Identification of standard autonomous-system to autonomous-system routing protocols appropriate for multi-network/cross-network path management.

Advantages and disadvantages of implementing path-vector, distance-vector and link-state routing protocols in dynamic networks

Development of predictive (leading indicator) routing protocols and/or similar performance models that balance traffic priority and volume versus route persistence/route expiration in dynamic networks

Alternatives to Transmission Control Protocol that provide reliable delivery in dynamic, long-distance/greater packet or bundle delay environments and minimize control traffic (overhead) and latency

On-Orbit Network Management

Strategies to monitor network performance, manage nominal network operations, and maintain on-orbit nodal positions in-plane and out-of-plane

Strategies for on-orbit fault identification and on-orbit network self-healing/correction responses

Suggestions for managing software updates throughout the network with minimal or no disruption to operations or services

Feasibility and approach of adding/removing/discovering users (new/old source and destination addressees) to the network

Network Security

Suggestions for ensuring data provenance, confidentiality and integrity within a dynamic network

Implementation strategies that ensure cyber security within the borders of the proposed Transport Layer constellation architecture

Novel approaches to on-orbit data encryption with respect to broader integrated government and commercial network elements and comingled data in transit

System Design

Estimations of Size, Weight, Power, and Cost (SWAP-C) for proposed on-orbit routing and storage hardware, to include the OISL physical layer elements

Opportunities and pros/cons of applying machine learning to dynamic, on-orbit networks operations and management

Identification of issues and suggested mitigation strategies to identify and manage critical system interfaces to ensure an open architecture approach

Identification and evaluation of OISL agility parameters for normal-mode intra- and inter-plane crosslinks within a single constellation design. Feasibility of crosslinks from one constellation design to another (i.e., crosslink operations between a Walker-Star constellation at altitude1 and a Walker-Delta constellation at altitude2 where altitude2 ≈

1.1 to 1.3 x altitude1)

Responses to this RFI will inform SDA’s Transport Tranche 0 solicitation in Spring 2020 as well as future SDA solicitations related to NDSA capabilities. Additionally, information obtained from this RFI will be shared with the OUSD(R&E) Fully Networked Command, Control and Communications (FNC3) Directorate.

SUBMISSION INSTRUCTIONS

All responses to this RFI must be received no later than 5:00 pm (Eastern) on Monday, 17 February 2020.

Responses are limited to no more than 8 pages, and shall use a minimum of 12-point font and 1 inch margins.

Responses shall be sent electronically to:

osd.pentagon.ousd-r-e.mbx.sda-sn-20-0002@mail.mil

Responses to this notice shall include Vendor's Company Name, Address, and Contact Information.

When submitting a response, please use the subject "SDA OISL Open Standard RFI Response - [Vendor Name]".

Any responses submitted through different channels or to a different email address will not be considered.

Organizations are encouraged to limit to a single response.

If a vendor would like to include classified information, please submit an unclassified response as requested with a classified addendum. Contact the above mailbox for classified submission instructions. Please indicate the classification level desired.

Classified addendums are subject to same submission deadline but are further limited to one page in length, 12 pt. font.

DISCLAIMERS AND IMPORTANT NOTES

This announcement contains all information required to submit a response. No additional forms, kits, or other materials are needed. This is an RFI issued solely for information and planning purposes; it does not constitute a formal solicitation for proposals. In accordance with FAR 15.201(e), responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. Submission of a response is strictly voluntary and is not required to propose to a subsequent SDA solicitation. No solicitation exists; therefore, do not request a copy of the solicitation. If a solicitation is released, it will be synopsized on the Federal Business Opportunities website. It is the responsibility of any potential offerors/bidders to monitor this site for release of any solicitation or synopsis. The SDA will NOT provide reimbursement for costs incurred in responding to this RFI or participating in any subsequent workshop. SDA will acknowledge receipt of all submissions but is under no obligation to provide feedback.

To the maximum extent possible, please submit non-proprietary information. If proprietary information is submitted, it must be appropriately and specifically marked. It is the submitter's responsibility to clearly define to the Government what is considered proprietary data. Any proprietary information should be clearly labeled as "Proprietary." The SDA will not publicly disclose proprietary information obtained as a result of the RFI. To the full extent that it is protected pursuant to the Freedom of Information Act and other laws and regulations, information properly identified by a respondent as "Proprietary" will be appropriately controlled.

Submissions may be reviewed by Government personnel and support contractors bound by appropriate non-disclosure agreements. Responses to this RFI will not be returned. Intellectual or other privileged or proprietary information contained in responses to this RFI will not be distributed outside of the Department of Defense or United States Government employees from other Government agencies who are working with the SDA on this RFI. Respondents are advised that the SDA is under no obligation to acknowledge receipt.