Data_Call_012_Computing Infrastructure Software for Survivable Command Posts_Amended 20220302.pdf

Solicitation: BAA-18-R-STCD Data Call 012 Topic #: S1830

APPROVED FOR PUBLIC RELEASE

APPROVED FOR PUBLIC RELEASE

BAA-18-R-STCD

WHITE PAPER CALL 012

Computing Infrastructure Software for Survivable Command Posts

Date 22 FEB 2022

This call for White Papers (WP) is being issued under Broad Agency Announcement (BAA) BAA-18-R-STCD, which was published on FedBizOpps.gov on 20 June 2018, and last updated on 01 February 2022. Respondents must refer to the solicitation document entitled BAA-18-R-STCD _ 20180620 BAA Final Rev15 (01Feb22), and it must be read in conjunction with this call for WP’s. All instructions set forth in the BAA-18-R-STCD solicitation document apply to this call.

The Research & Technology Integration Directorate (RTI) is issuing this call for WP’s in association with Topic # S1830. To be eligible for consideration and possible contract award, the technology or methodology shall be either basic research, applied research, advanced technology development not for a specific system/hardware, or demonstration and validation.

ADDITIONAL INFORMATION:

Problem Statement:

The Army is currently working to transition from tent-based, static, monolithic command posts (CPs) to more agile, expeditionary, and physically dispersed CPs. The computing infrastructure that supports Army CPs reflects their static and monolithic nature, and must also evolve to support this transition. C5ISR Center RTID is seeking to develop a new software-based CP computing infrastructure that is capable of supporting an agile, expeditionary, survivable CP at echelons from battalion (BN) to Corps. The desired capabilities include:

1. Robust fault tolerance, able to operate in denied/disconnected, intermittent or limited (DIL) network conditions without undue performance impact

2. Ad-hoc clustering, able to rapidly form and break clusters of shared resources in response to frequently-changing battlefield conditions

3. Support for 1-n number of nodes

4. Single Pane Management

5. Support for cloud technologies (e.g. software containers, software-defined networking)

6. Support for virtual machines

7. Support for distributed data stores/hyperconvergence and dedicated storage appliances

APPROVED FOR PUBLIC RELEASE

APPROVED FOR PUBLIC RELEASE

8. Hardware-agnostic, able to extract maximum performance from both resource-rich and –poor platforms

9. Support for pass-through to specialized hardware (e.g. GPUs)

10. Support for CONUS cloud providers (e.g. AWS, Azure) and able to move data and workloads bidirectionally

11. Support for automated deployment & configuration management tools (e.g. Ansible, Terraform)

12. Support for data-at-rest encryption

Information Sought:

C5ISR Center Research & Technology Integration Directorate (RTI) is interested in receiving WPs on the above topic from companies that have extensive experience in developing software for cloud computing, software-defined infrastructure, and Infrastructure as a Service (IaaS) applications. The identified technology solution(s) should be at technology readiness level (TRL) 4 or higher but not over TRL 6 to be considered. Novel combinations or reconfigurations of higher-TRL solutions will be considered. The end state of the identified solution should be a demonstration/proof of concept system at TRL 6 that can be tested and verified in an operationally-relevant environment, then transitioned to an Army program of record.

Possible solutions can be single-product, an integrated suite of products, or a novel combination or reconfiguration of currently-fielded Army systems. Software-only solutions as well as integrated hardware/software solutions will be considered. Companies may also include in their proposal solutions for network services (e.g. Identity & Authentication Management (IDAM), key management) that are relevant to the problem statement or are enablers for the desired capabilities identified above.

It is essential that any identified solutions have a clear path to be matured and commercialized to meet other important system goals including, but not limited to:

affordability, supportability & sustainability, trainability, cybersecurity and authorization under the DoD Risk Management Framework (RMF).

AWARD INFORMATION:

1. ANTICIPATED AWARD DATE: June 2022

2. FUNDING: Under this call, the Government intends to award one contract with a Period of Performance (PoP) of a 12 month base and one (1) 12 month option. The option years are not guaranteed and are based on funding availability. The anticipated funding for this call is up to $2,000K for the total contract ceiling, however, the Government reserves the right to award smaller or larger contracts or assistance instruments.

APPROVED FOR PUBLIC RELEASE

Topic #: S1830

APPROVED FOR PUBLIC RELEASE

NOTE: This funding profile is an estimate only and not a contractual obligation for funding. All funding is subject to change due to Government discretion and availability.

Potential respondents should be aware that due to unanticipated budget fluctuations funding in any or all areas may change with little or no notice. Awards under this call are expected to range from $2,000K to $3,000K. The Government reserves the right to select all, part, or none of the WP’s received, subject to the availability of funds.

3. BAA TYPE: This is a call for WP’s only, and will be governed by the “two-step” process described in General Information of the BAA-18-R-STCD. Respondents that submit a proposal without first submitting a WP may not be eligible for award.

4. SUBMISSION INSTRUCTIONS: This call provides general public release requirements ONLY. Additional technical detail can be requested by contacting all POCs below, being sure to provide DUNS and/or CAGE numbers in the request.

This Call should not exceed ten (10) pages in length (single sided, single spaced, with 12-size font). The ten (10)-page limitation does not include the Rough-Order-of- Magnitude (ROM) or the Cover Page. Refer to baseline BAA-18-R-STCD Section III for all other instructions on WP preparation, submission, and evaluation.

5. QUESTIONS DUE DATE AND TIME: Technical questions are due no later than 01 March 2022, 3:00 pm EST via email to the Technical Point of Contact (TPOC) with a carbon copy (Cc) to the Contracting Officer (KO), Contract Specialist (KS), and Acquisition Management Team (AMT) Mailbox, as listed below. Questions and answers will be posted to FBO.

Government will publish questions and answers received by industry to FBO, via a revision to this Data Call, per ADDENDUM 001, Technical Questions and Clarifications, herein.

6. WHITE PAPER DUE DATE AND TIME: WP’s are due no later than 10 March 2022, 3:00 pm EST via email to the Technical Point of Contact (TPOC) with a carbon copy (Cc) to the Contracting Officer, Contract Specialist, and AMT Mailbox, as listed below.

TPOC: Bradford Stevenson, bradford.j.stevenson.civ@army.mil

AMT: usarmy.apg.devcom-c5isr.mbx.rti-baa@army.mil

KO: Christopher Fisher, christopher.m.fisher24.civ@army.mil

KS (1): Christina Sanzone, christina.l.sanzone.civ@army.mil

KS (2): Matthew Strong, matthew.r.strong9.civ@army.mil

If the submission will be classified, respondents should contact the TPOC and KO for instruction on how to submit the WP, via appropriate methods/channels. The KO shall

APPROVED FOR PUBLIC RELEASE

Topic #: S1830

APPROVED FOR PUBLIC RELEASE

be informed, in writing, that a classified WP has been submitted, its title and to whom it was submitted to.

Contractual questions may be directed to the KO and/or KS at any time.

ADDENDUM 001

to

Data Call 012

Technical Questions and Clarifications

02 March 2022

NOTE: For the protection of Controlled Unclassified Information (CUI), selected Government responses to the technical questions are redacted. To receive a fully disclosed version of the Q&As, please submit a request, providing your DUNS and/ or your CAGE Number, to the RTI Acquisition Management Team (AMT) email address, with a carbon copy (Cc) to the Contracting Officer (KO) and the Contract Specialists (KS) listed below:

AMT: usarmy.apg.devcom-c5isr.mbx.rti-baa@army.mil

KO: Christopher Fisher, christopher.m.fisher24.civ@army.mil

KS (1): Christina Sanzone, christina.l.sanzone.civ@army.mil

KS (2): Matthew Strong, matthew.r.strong9.civ@army.mil

Q&As

Q1: (U) The Data Call states: The identified technology solution(s) should be at technology readiness level (TRL) 4 or higher but not over TRL 6 be considered. What is the reason for not considering solutions over TRL 6?

A: (U) The TRL 6 threshold is both a function of the contract vehicle (Broad Agency Agreements are intended for use for 6.2/6.3 efforts) and of the nature of the effort (most of the COTS solutions to this problem that we’ve seen would be low-TRL when considered in a tactical environment). That said, we’d consider novel configurations or applications of otherwise high-TRL products to be lower-TRL.

Q2: (U) Is this S&T effort viewed as part of PM Mission Command’s modernization path for the CP CE Program of Record? Is this envisioned to be a tech transition to CP CE?

A:

Q3: (U) When considering solutions for a disbursed/distributed computing environment to what extent do we have to factor in the current CP CE solution and architecture?

A:

Q4: (U) The Call for White Paper does not specify a requirement to be able to digitally collaborate while the CP is dispersed. Is that an implied requirement?

A: (U) Collaboration tools are not explicitly part of this WP call and may be addressed in future calls, but can be included under the auspices of the “related services or other enablers” language of this call if you like.

Q5: (U) Desired capability #1 “Robust fault tolerance, able to operate in denied/disconnected, intermittent or limited (DIL) network conditions without undue performance impact” seems to conflict with desired capabilities #5, #7, and #10. Will you accept a degraded performance in the event of a loss of outside communications?

Q9: (U) Would you consider several mobile enterprise solutions (i.e., mobile field server) that can host locally many of the battlefield tools required to operate if all outside services are lost?

A: (U) The intent is to support operation in all network conditions including complete loss of reachback connectivity, so this would be not only desirable but required.

Q10: (U) What mobile platform(s) are you envisioning this for (e.g.,Command Post Integrated Infrastructure < Caution-https://peoc3t.army.mil/mc/cpi2.php > (CPI2)), and what hardware comes with them?

A:

Q11: (U) What kind of network topology & infrastructure is available? Will we be responsible for establishing a secure network connection between command posts or does our job begin when the command post comes online?

Q12: (U) What types of applications/processes are being run at a command post?

What are expected traffic conditions?

Q13: (U) What types of failures are expected? How would you describe expected network conditions (intermittent?) What kind of robust behavior is desired? What are the expected complications/current challenges as you understand them?

A: (U) Possible failures include degradation or loss of connectivity between shelters or compute nodes and loss of a shelter and accompanying compute node due to equipment failure or enemy action. An example of a behavior we would expect from a robust system: assuming a hyper converged hosting platform with storage distributed across multiple nodes, after a loss of a certain number of critical nodes the storage system will alert the user and stop operating in order to prevent corruption of data. This is because there is an assumption baked into the system that data corruption is the worst thing that could happen. A hosting platform geared towards a tactical environment might instead inform the user of the risk of corruption and allow them to decide, or present a list of workloads that can continue to operate in a degraded state, because the worst thing that can happen is that those services are no longer available.

Q14: (U) In addition to GPUs and dedicated storage, what other sorts of specialized pass-through hardware needs to be supported?

A: (U) At present no other specific hardware is anticipated, but proposed solutions should ideally be able to support pass-through of any future devices on standard buses (e.g. PCIE, USB)

Q15: (U) Does CPI2 plan to use CP hardware or TSI small kit they already own and just looking for a hyper-converged software solution?

A: (U) The hardware-agnostic requirement is intended to a) ensure that whatever solution we arrive at is backwards-compatible to older platforms to ensure availability to COMPO 2 & 3 units and b) not constrain future hardware selections. That said, proposals for integrated hardware/software solutions will be considered if they provide a compelling benefit.