20230809-ABMS_CDN_RFI Final.pdf

Advanced Battle Management System Content Delivery Network RFI 09 August 2023

Advanced Battle Management System (ABMS) Content Delivery Network

Request for Information (RFI)

Department of the Air Force PEO Command Control Communications and Battle Management (PEO C3BM)

RFI exploring Content Delivery Network concepts to support Advanced Battle

Management System (ABMS) Acquisition Efforts

A. PURPOSE

The Department of the Air Force PEO for Command, Control, Communications, and Battle Management (DAF PEO C3BM) is exploring Content Delivery Network (CDN) concepts to support an Advanced Battle Management System (ABMS) / DAF BATTLE NETWORK efforts. DAF PEO C3BM seeks industry feedback on:

1. The concept of a CDN as described in this RFI.

2. The viability of commercial and defense solutions to meet the CDN concept and objectives within this document.

3. Industry assessment of the largest challenges facing the deployment of a CDN.

4. Industry assessment and rough order of magnitude on the costs associated with deploying the CDN concept.

5. Industry assessment of the concept, use cases, and objectives of the CDN and an assessment of how well suited they are for executing on the above.

The envisioned CDN solution will be one of many products within the ABMS Digital Infrastructure (DI). The CDN solution will provide a data abstraction layer that will position data objects hosted in ABMS Commercial CONUS cloud environments and ABMS Fixed Sites (e.g. Tactical Operations Center Fixed, Air Operations Center, etc.), at multiple security levels, closer to the deployed and mobile nodes in theater. The CDN solution will be cloud agnostic to provide a consistent caching layer into which any Cloud Service Provider edge node can interface. The CDN solution will focus on how to optimize warfighting activities by creating a global distribution of data object caches that can be forward deployed and at fixed sites.

This CDN RFI is one of two RFIs intended to request information from industry on the development of a CDN solution. Interested parties that receive both RFIs should respond to only one RFI, based on which RFI applies to them.

Responses to this Request for Information (RFI) will be used as market research and to create acquisition strategy documentation for the future procurement of the Content Delivery solution. Interested parties are encouraged to submit responses as outlined in the White Paper Template.

IMPORTANT: Your submissions MUST be strictly UNCLASSIFIED. You are responsible for ensuring your submission content complies with the aforementioned level/standard.

B. BACKGROUND

ABMS Acquisition Efforts are not envisioned as a traditional program of record with a single prime contractor that develops company-specific solutions, but rather an open architecture family of systems that enables capabilities via multiple integrated capabilities and leverages both commercial and defense technology and partnerships.

ABMS Acquisition Efforts require continuous incremental progress to build an enduring digital infrastructure that ultimately enables the joint warfighter to better sense, make sense, and act by connecting the right sensor and the right data, with the right decision maker in order to direct the actions of the best shooter.

The ABMS DI will be the foundation of ABMS and the Battle Network that provides a global, resilient, distributed infrastructure for providing the warfighter the BMC2 data they require to make optimal operational decisions. The ABMS CDN will be one product within the ABMS DI that interfaces with other ABMS DI products.

C. ABMS CDN Concept

The ABMS CDN will position data to enable multi-domain dynamic operations and Denied Degraded Intermittent and Latent (DDIL) resilience by:

• Creating a distributed system of global caches that will be deployed at ABMS Fixed DI Sites and along with ABMS deployed/mobile nodes;

• Leveraging intelligent content distribution algorithms to optimize application performance and retain synchronicity between tactical BMC2 nodes in theater;

• Providing AOR aware content distribution to optimize which data is positioned across global theaters;

• Supporting both a virtual and hardware appliance such that distributed caches can be scaled based on the compute infrastructure of the ABMS node; and,

• Enabling content distribution across the following security enclaves: Unclass/CUI, Secret, Secret // REL, SECRET // SAR, TS // SCI, TS // SAR.

The ABMS CDN will have many potential use-cases across four ABMS DI classes:

• Hyperscale DI:

o Hyperscale DI will be the common source of truth and the provider of enterprise services, data, and applications.

o The CDN will consider the Hyperscale DI the ultimate origin for all CDN points of presence.

o The Hyperscale DI is cloud-specific; services, data, and applications could be hosted within separate cloud providers.

o Hyperscale DI is the initial origin point and built within the managed services of cloud service providers.

o DDIL Risk: Low

• Fixed DI:

o In this use case, the compute and networking infrastructure at the fixed sites can be expected to be large and stable. With the Hyperscale DI being an origin point and the fixed sites a child node.

o Fixed Sites will be the primary interface to the Hyperscale DI.

o Fixed DI is an origin point to deployable and mobile DI, but a child node of

Hyperscale DI.

o DDIL Risk: Low to Medium

• Deployable DI:

o Deployed nodes are nodes that are deployed in place and can take the role of an

Agile Combat Employment (ACE) Hub or Spoke depending on the mission and compute infrastructure included with the deployment.

o Deployed Nodes will primarily interface with Fixed Sites for collecting data from the Origin (CONUS Cloud).

o Deployed Nodes will pass cached data amongst themselves, including data that is pulled from Fixed Sites and data that is required to maintain common, synchronous situational awareness amongst deployed nodes.

o If Fixed Sites are no longer operational, deployed nodes will leverage intelligent content routing to receive data from the Hyperscale DI Origin.

o DDIL Risk: Medium to High

• Mobile DI:

o Mobile nodes can be terrestrial or aerial and operate in environments where DDIL conditions are prevalent both from an operational context and from the nature of maintaining persistent network access while in motion.

o Mobile nodes will interface with any other form factor of distributed cache that is available due to their connectivity challenges.

o Mobile Nodes will pass cached data that is required to maintain common, synchronous situational awareness amongst Mobile and Deployed Nodes.

o DDIL Risk: High to Certain

D. ABMS CDN Use Cases The following use cases reflect potential operational and technical use cases of the ABMS CDN with regards to an initial deployment and its implications for the warfighter.

1. Scene Setter: The DAF BATTLE NETWORK system-of-systems includes hundreds of nodes across the C3BM Enterprise. These nodes will include a combination of fixed, deployable, and mobile nodes distributed globally. Each of these nodes will operate at various levels of classification and will have access to a common SD- WAN that provides a global black fabric. The global black fabric will connect to a Hyperscale CONUS infrastructure. The Hyperscale CONUS infrastructure will operate at all levels of classification through a seamless MLS architecture. The Hyperscale CONUS infrastructure will act as the interface between the necessary support services and the distributed nodes. These support services will include, NOC/SOC services, configuration tracking and management, software patching, application updates, identity services, data aggregation, and other services.

2. All use cases are described in the context of the competition continuum described in Joint Doctrine Note 1-19 dated 03 June 2019.

3. Cooperation CDN Use Cases:

a. During cooperation operations the routine maintenance, patching, and management of distributed nodes will be conducted through the global black fabric by pushing/pulling updates from the hyperscale infrastructure.

b. Rather than have every distributed node pulling data directly from the hyperscale infrastructure, data will be pulled from the hyperscale infrastructure to a set number of fixed sites across the geographic COCOMs. The fixed sites will cache large quantities of data objects and push those data objects to the deployed nodes. The fixed sites will also pull data objects from deployed nodes for future aggregation within the hyperscale infrastructure.

c. Operators will be leveraging the distributed nodes for training activities and continuous test events.

d. During this phase of the competition continuum the most stressing use-case will be the continuous management of the configuration of the global distribution of nodes along with short periods of operational activity limited to a targeted geographic area.

e. The risk of kinetic attacks against any of the distributed infrastructure is low.

f. Non-kinetic activities must still be regularly monitored due to potential rogue actors that may choose to threaten the DAF BATTLE NETWORK. State actors may probe the DAF BATTLE NETWORK in attempts to gain intelligence on U.S.

operations.

g. Zero-day vulnerabilities are a risk for all nodes/applications on the -network, and although these vulnerabilities may not directly impact operations, mitigations must be in place to prevent wide scale operational impacts.

h. It is expected the ABMS CDN will provide support to all the above functions during cooperative operations and provide another layer of protection to the distributed nodes on the DAF BATTLE NETWORK to prevent exploitation of zero-day vulnerabilities.

4. Competition below armed conflict CDN Use Case

a. During the competition below armed conflict phase, all risks and operational activities within the cooperation phase exist and are compounded by the new competitive environment.

b. In this phase, it is anticipated that non-kinetic activities have expanded as competitive states are allocating resources with the intent to gain a competitive advantage in preparation for an armed conflict phase, or to force political decisions to the disadvantage of the United States.

c. The operational demand on the DAF BATTLE NETWORK has increased as the geographic combatant command of interest now postures itself for potential armed conflict.

d. Large scale joint and coalition exercises within the geographic combatant command of interest for the purposes of demonstration of force are more frequent.

e. Data being pulled from the hyperscale infrastructure is more frequent.

Distributed and mobile nodes focus their activities around operating under DDIL conditions.

f. The movement of data within the DAF BATTLE NETWORK now reflects the potential operational demand as more data gets pre-positioned in the theater of interest.

g. Data objects may be cached for longer periods of time and further away from the hyperscale infrastructure.

h. Various data objects become more prevalent such as video, imagery, XML/JSON, and other data types.

i. Updates to the configurations of distributed nodes may be reduced as more nodes get deployed in theater and disconnected, with sporadic updates to the distributed nodes as they regain connectivity to the DAF BATTLE NETWORK and accept SW/patch updates.

j. Fixed sites continue to operate as the primary mechanism for pulling/pushing data to the hyperscale infrastructure to limit long-haul bandwidth constraints across the geographic COCOMs.

5. Armed Conflict CDN Use Case:

a. During this phase of the competition continuum, it is anticipated that armed conflict kinetic activities are limited to the theater(s) of interest, with all activities/risks within the cooperation phase still present and potentially the competition below armed conflict phase as well.

b. Within the armed conflict phase, all distributed nodes within the theater(s) of interest are at risk of kinetic attack, with non-kinetic activities creating DDIL conditions.

c. Deployed and mobile nodes within theater should expect to experience a certain degree of DDIL conditions. Nodes will have access to the data generated locally, and when connectivity is enabled, they will re-synch and push/pull data from other nodes within theater and the hyperscale infrastructure.

d. All deployed and mobile nodes will act as caches of live warfighting information and will need to push that information to other nodes throughout the theater to maintain common battle space awareness.

e. Connectivity between distributed nodes in theater will be contested with bandwidth being sparse such that the transfer of data between nodes needs to be optimized to enable warfighting operations. The distribution of caches in theater and how/when data gets cached must be intelligently planned and optimized.

f. The maintenance and configuration of nodes in theater will take a back seat to enable operational data to take priority. This will introduce potential risks in the non-kinetic environment as distributed nodes start to stray from a common baseline configuration and security patches become less frequent when nodes are operating in theater.

g. Cached security updates must be intelligently staggered such that when a node that is disconnected for long periods of time, it will not be rendered inoperable by being forced to update its security configuration for extensive periods of time.

h. While a node is updating its security configuration, it may be necessary to isolate it from the larger network, but keep it connected to the appropriate cache to receive the security update. This CONOP would promote security of the overall network while enabling a largely distributed and dynamic node distribution.

i. During armed conflict, it may be the case that a fixed site is rendered no longer operational and the deployed / mobile nodes must interface directly to the hyperscale infrastructure. In this situation there must be an intelligent way of deciding which deployed / mobile node should be the primary interface to the hyperscale infrastructure such that backhaul communication bandwidth is not consumed by multiple requests to the hyperscale infrastructure.

j. Caches must have some level of awareness of the underlying network and proximity to other nodes throughout the theater to correctly optimize how data will flow within the network such that nodes that require a specific data object are reaching out to the node that has that data object within the closest proximity (where proximity is determined intelligently by the CDN solution).

E. ABMS CDN OBJECTIVES

1. The ABMS CDN will cache the following data types:

a. Static Data (.jpeg, .png, map tiles, other objects) leveraged by BMC2 applications

b. Firmware and Software updates pulled from origin points

c. Mission Data (XML, JSON, etc) to maintain synchronicity across edge nodes

d. Full Motion Video

2. The ABMS CDN will enable the deprecation of stale data across edge devices.

3. The ABMS CDN will enable application aware rate limiting.

4. The ABMS CDN will include video buffering capability to support video live streaming

5. The ABMS CDN will be accredited for use at the Unclass (CUI), SECRET, TS/SCI, and

TS/SAR security enclaves

6. The ABMS CDN will provide a web application firewall capability

7. The ABMS CDN will provide API acceleration capabilities

8. The ABMS CDN will be available as a virtual appliance

9. The ABMS CDN will be available as a hardware appliance

10. The ABMS CDN will push data from origin points to end user nodes

11. The ABMS CDN will pull data from end user nodes to origin points

12. The ABMS CDN will include geo-blocking capabilities

13. The ABMS CDN will provide application load balancing capabilities

14. The ABMS CDN will shield the origin point

15. The ABMS CDN will leverage existing DNS services or provide its own DNS service

16. The ABMS CDN will provide distributed denial-of-service (DDoS) protection

17. The ABMS CDN will provide bot detection and protection

18. The ABMS CDN will validate the provenance of data pulls/pushes from end-points and the origin

19. The ABMS CDN will enable and ensure data provenance when moving data between the origin and edge nodes

20. The ABMS CDN will be hostable on compute/storage limited distributed nodes

21. The ABMS CDN will support orchestration through a container management solution

22. The ABMS CDN will support virtualization through hosting on a virtual machine

23. The ABMS CDN will provide data caching optimization capabilities

F. INDUSTRY FEEDBACK ON ABMS CDN Concept, Use Cases and Objectives

The ABMS Program Office requests industry feedback on the overall concept, the use cases, and the objectives for the ABMS CDN product:

1. What do you assess as the largest technical challenges for deploying a global CDN capability as described in the CDN concept?

2. What do you assess as the largest policy challenges for deploying a global CDN capability as described in the CDN concept?

3. What commercial-off-the-shelf capabilities do you believe would meet the CDN concept and objectives of this RFI?

4. How would you architect the ABMS global CDN? The following assumptions apply:

a. Hyperscale, Fixed, Deployed, and Mobile nodes exist and are developed/maintained by a separate integrator(s).

b. The transport system for the CDN exists as a separate product within the ABMS

DI, or existing DAF enterprise provided capabilities provided by a separate integrator.

5. What non-commercial capabilities would you recommend be included or developed to meet the CDN concept and objectives?

6. What concerns do you have with the ABMS CDN concept, use cases, and objectives?

7. What expertise or past performance/experience do you have in deploying this capability?

8. What cost factors should the Government be aware of when deploying a global CDN?

9. How would you integrate the CDN solution with pre-existing deployed nodes/fixed sites

(e.g. Lead Wing, AOC, Control and Reporting Center (CRC), etc.)

10. If separate integrators are developing the four foundational DI classes, how would you partner with them to incorporate the CDN solution into that infrastructure?

11. How would you integrate your CDN solution with the four foundational DI classes?

12. What experience does your company have in the deployment of a global CDN?

G. SUBMISSION INSTRUCTIONS

Interested vendors should respond utilizing the attached ABMS Content Delivery Network White Paper (attachment A) submitted electronically to nicomedez.correa.1@us.af.mil and wesley.livesay@us.af.mil . White paper submissions should be no longer than 20 pages, with font-sizes no smaller than 10.

Attach the completed ABMS Content Delivery Network White Paper Template to your scout card submission in Vulcan, ensure it is filled out in compliance with the stated content restrictions, and utilized portable document format (PDF).

• Fill out all fields in the ABMS Content Delivery Network White Paper Template and attach it using attachment section of scout card submission form. Select attachment type as “White Paper” and also select it as “Required.” Some fields in the attachment may seem redundant to Vulcan, but they are purposefully applied to enhance the evaluation process.

mailto:nicomedez.correa.1@us.af.mil mailto:wesley.livesay@us.af.mil

Upon submission, you will receive an onscreen confirmation verifying your submission was received. Do NOT submit duplicate solutions or scout cards.

DO NOT SUBMIT CLASSIFIED INFORMATION in the response. It is incumbent on YOU the entity submitting the response to ensure any restrictions are outlined in the response.

All responses shall be provided at an unclassified level. Respondents shall indicate whether their responses contain proprietary information, and all proprietary information and figures shall be clearly and individually portion marked as proprietary. It is the respondent’s responsibility to clearly mark and define to the Government what is considered proprietary data.

ABMS CDN RFI submissions must be received no later than 31 August 2023, NLT 0900 EDT. No contracts will be awarded based solely on this announcement.

White papers must be submitted directly to the contracting team via DoD SAFE by the stated deadline. The Offeror can request a DoD SAFE drop-off email and instructions in advance of white paper submission. The link contained in the email will remain valid for fourteen (14) days after the code has been sent to the Offeror. Questions regarding DoD SAFE may be directed to the contracting team.

H. ADDITIONAL INFORMATION

White Paper Classification and Proprietary Information:

All responses shall be provided at an unclassified level. Respondents shall indicate whether their responses contain proprietary information, and all proprietary information and figures shall be clearly and individually portion marked as proprietary.

It is the respondent’s responsibility to clearly mark and define to the Government what is considered proprietary data. The white papers will be reviewed by Government, Federally Funded Research and Development Center (FFRDC) personnel, and Systems Engineering Test and Acquisition (SETA) government support contractors.

DISCLAIMER: This RFI (Request for Information) is issued solely for information and planning purposes and does not constitute a solicitation. The DAF PEO C3BM is not seeking proposals at this time and will not consider unsolicited proposals provided in response to this RFI. All responses will be in the form of information and materials.

This announcement serves as a notice and invitation to ask for industry assistance in responding to the included questionnaire. All information received in response to this RFI that is marked as proprietary will be handled accordingly. 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. Responders are solely responsible for all expenses associated with responding to this RFI.