SDA-SN-21-0007 T1 Space Mesh RFI.pdf

Space Development Agency

Space Mesh Networking Capabilities and Interoperability Request for Information

SDA‐SN‐21‐0007

The Space Development Agency (SDA) seeks industry feedback on in‐space networking capabilities to inform SDA’s future solicitations, including the Tranche 1 solicitation anticipated for Fall 2021.

Background

The National Defense Strategy (NDS) acknowledges that space is vital to the U.S. way of life, 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 developing, fielding, and operating the Department’s next‐generation 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. SDA organizes its architecture into capability “layers” and predicated on the availability of ubiquitous data and communications transport provided by relatively small, mass‐produced satellites and tactically relevant payload hardware and software.

SDA expects the T1 Transport Layer (T1TL) to comprise approximately 150 space vehicles, developed and manufactured by multiple vendors, launching in late FY2024. SDA plans to release Draft Request for Proposals (RFP) for the T1TL program in Summer 2021.

Comprehensive solutions that include open architectures (e.g., buses that support multiple payloads and software applications and payloads/software capable of integration aboard multiple buses or flight processors) and leverage commercial capabilities, existing or planned, are preferred. Additional solicitations for other capability layers will be based on identified requirements and availability of funds.

SDA expects the T1TL constellation to feature six near‐polar circular planes with tens of satellites at 1000 km altitude in each plane. In Tranche 1, SDA is interested in deploying a homogeneous constellation design, with all space vehicles equipped with baseline mission payloads, as currently described in SDA‐SN‐21‐0003.

SDA’s Request for Information (RFI) SDA is seeking information on potential space networking solutions for Tranche‐1 to transport IPv4 and IPv6 traffic, possibly using a sub‐IP technology such as MPLS or switched Ethernet.

Network planning, management, and monitoring operations – SDA recognizes the critical importance of these functions. The effective operations of a complex integrated space and ground mesh network comprising the NDSA is central to the delivery of all of the supported operational mission capabilities. SDA does not anticipate significant new development in this area, but we look forward to recommendations of companies that can provide these services.

Responsibilities for routing and monitoring include three levels of mesh management: 1) Provisioning routes; 2) Monitoring links between nodes; 3) Monitoring nodes. Solutions must address proliferated constellation networking such as software‐defined networking or other options which enable vehicle agnostic reconfiguration or reprogramming from the ground to include automatic re‐routing of services during anomaly/outage situations. A sufficient level of network situational awareness is required to support Quality of Service tracking, efficient resolution of anomalies and system performance assessment.

SDA network architecture vision

The network architecture provides IPv4 (RFC791, RFC1122) end‐to‐end communication over an MPLS/VPN (RFC 3031, RFC3032, RFC4364) traffic‐engineered backbone, coordinated using commercial network management protocols (e.g., Netconf RFC6241, SDA OpenFlow RFC7426).

It uses precomputed, predeployed time and ephemeris‐based forwarding tables and automation to adjust the backbone to account for orbital dynamics. The architecture relies on Adaptive Queue Management (AQM, RFC 7567) and Explicit Congestion Notification (ECN, RFC 3168 and RFC 5129) support to reduce latency, as well as the Diffserv (differentiated services, RFC2474 and RFC5129) architecture of edge policing and shaping with configurable core weighted queuing to support traffic prioritization. Internal components leverage Ethernet (IEEE 802.1q) for local interconnect and Internet “transport” protocols (TCP/CUBIC RFC793 and RFC8312, UDP/QUIC RFC768) for end‐to‐end reordering, retransmission, and congestion avoidance, as well as IP‐based encryption (IPsec, HAIPE) for red‐black separation between IP endpoints. Nodes include space vehicles (SV), Optical inter‐satellite links (OISL), SV Ka‐band transceivers, Link‐16 networks, Ground entry points (RF and optical), and Operations centers. RFC and IEEE references are provided for context; ICDs will indicate exact requirements.

Upon initial deployment, each space‐vehicle vendor (SVV) will be responsible for the provisioning and monitoring of all links and nodes within their segment of the T1TL constellation and providing link and node inputs to the SDA operations locations. SDA expects to use either in‐ house developed or third party supplied software to electronically provide connection and routing details between SVVs’ networks. At this stage network management functions will execute in the space‐vehicle’s primary mission processor and be provisioned and monitored from the ground. Evolutionary upgrades to the BMC3‐module’s software and ground systems will support increasing autonomy and optimization to the network provisioning and monitoring capabilities. SDA will require that SVVs’ network management systems support a graceful transition of control to autonomous systems, while maintaining full contingency operation options.

SDA expects to execute an experimental design and implementation plan demonstrating increasing capability and autonomy within and between SVV networks and ground nodes (ground entry points, operations centers, and Link‐16 networks) migrating from largely static SVV‐based management to largely autonomous BMC3‐based management. Measured demonstrated success will be required before moving to the next level of autonomy.

Please answer the following detailed questions in order to inform SDA of the current state‐of‐ the‐art regarding commercial, ready‐for‐space, network capabilities. In your answers to the following, provide references to standards where relevant and appropriate. Please provide summaries of any deviations from referenced standards where they are insufficient.

General Please describe your protocol stack architecture. Please include any application, IP transport, routing, sub‐routing, and link‐layer data plane protocols used in your architecture.

What are the constraints on the sizes of IP packets the system can handle?

Does the system support multicast? If so, how is it configured / controlled / managed (e.g., PIM, IGMP, …)?

Can your system support the correct setting of IP ECN bits so that end systems can detect incipient congestion?

Describe the traffic engineering capabilities and/or support of your architecture.

What external hardware / software / system elements are needed to support the operation of your network subsystem?

Interfaces and Forwarding What interface technologies occur in your solution (e.g., Ethernet, high‐speed serial)?

How many high‐rate (appropriate for connection to the OISLs and spacecraft LAN) ports can your system support?

At what aggregate rate can your system forward IP packets with 70‐byte payloads?

What type of network or link‐layer protection/failure recovery mechanisms are supported by your system? How are they controlled?

How many forwarding table entries can be supported?

If you support MPLS, how many label operations (i.e., push, pop, swap) can you support per packet?

Do you support any form of multipath forwarding, and if so, by what mechanisms?

Traffic Classification and Queueing Describe the traffic classification mechanisms supported by your system.

Describe the queuing mechanisms and/or service disciplines supported by your system.

E.g., support for strict priority queueing, weighted fair queueing, etc.

Describe the OAM or INT mechanisms and/or support of your architecture.

What rate / flow control mechanisms can be used to prevent overrunning outbound links (e.g., rate control, Ethernet pause frames)?

Control and Diagnostic Capabilities Which management and/or SDN plane protocols are used in your architecture, and what role do they serve?

Which control plane protocols are used in your architecture, and what role do they serve?

What diagnostic capabilities does your system support? E.g., the ability to control packet paths through source routing or traffic engineering.

What network management protocols, data models, and network telemetry do you support (e.g., SNMP, MIBS // Netconf, YANG)?

What mechanisms does your system use to respond to on‐orbit fault conditions (identification and resolution)?

Scheduled Routing / Forwarding Configurations SDA systems need to support the storage and autonomous application of time‐tagged

(future) forwarding configurations. How many such configurations could your system support?

Can your system support atomic switches between forwarding configurations (e.g., atomic switching from one forwarding table to another)?

Crypto and security What is your planned network security architecture, include any PT/CT routing and/or switching?

How many concurrent security associations (or equivalent) will the Inline Network Encryptor (INE) support?

At what rates can the crypto device encrypt / decrypt?

Has the crypto solution ever been part of an Authority to Operate (ATO) for a government / military system?

Does the crypto solution support black‐side native multicast?

What packet handling markings, e.g., IP TOS or 802.1 PCP/DE bits, can INE be configured to copy or map between PT (red) and CT (black) interfaces?

How are your control, management, SDN protocols secured?

What is your planned key management approach?

Other What other relevant SDA tailored solutions are supported by your architecture/system?

System Design Estimations of Size, Weight, Power, and Cost (SWAP‐C) for proposed on‐orbit routing and storage hardware.

Are there any power savings from running the networking system at a lower rate? What are they?

Data Rights Please provide details on the data rights and licensing rights for the government associated with any intellectual property you outline in your response.

Information Use Policy Responses to this RFI will inform SDA’s Transport Tranche 1 solicitation in Fall 2021 and 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 Friday, 4

June 2021.

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‐21‐0007@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 Space Mesh 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.