National Oceanic and Atmospheric Administration (NOAA) Cloud Platform Management Services Request for Information (RFI)

***This announcement is hereby amended as of August 10, 2022 to include the first set of answers provided to the questions received to date for this announcment.*** 1.0 Description This is a Request for Information (RFI). NOAA is performing market research to identify cloud knowledgeable service offerors capable of providing cloud services and support services for the new Open Architecture Data Repository (OADR). This RFI is for informational purposes only; it is not a request for proposals or a solicitation for a contract or grant award and it does not obligate the Government in any way. The Government will not reimburse respondents for any costs associated with responding to this request. 1.1 Definitions, Acronyms, and Abbreviations API: Application programming interface. A standard interface by which a software module interacts with another software module. CCSDS: Consultative Committee for Space Data Systems. CDM: Conjunction Data Message. CPU: Central Processing Unit GFE: Government Furnished Equipment. GPU: Graphics Processing Unit HTTP: HyperText Transfer Protocol. A L5/L7 network protocol foundational to the modern internet. IaaS: Infrastructure as a Service JSON: JavaScript Object Notation. A data storage and transmission format, popular in modern web applications. NOAA: National Oceanic and Atmospheric Administration N-Wave: NOAA's secure 10GB per second fiber optic link that supports scientific research OADR: Open Architecture Data Repository, the full name for this project. OD: Orbit Determination. OEM: Orbit Ephemeris Message. A type of standard CCSDS Orbit Data Message. An OEM specifies the position and velocity of a single object at multiple epochs contained within a specified time range. The OEM is suited to exchanges that (1) involve automated interaction (e.g., computer-to-computer communication where frequent, fast automated time interpretation and processing is required), and (2) require higher fidelity or higher precision dynamic modeling than is possible with the OPM. OPM: Orbit Parameter Message. An OPM specifies the position and velocity of a single object at a specified epoch. Optionally, osculating Keplerian elements may be provided. This message is suited to exchanges that (1) involve automated interaction and/or human interaction, and (2) do not require high-fidelity dynamic modeling. PaaS: Platform-as-a-Service REST: Representational state transfer. REST is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. RESTful web APIs are typically loosely based on HTTP methods to access resources via URL-encoded parameters and the use of JSON or XML to transmit data. SSA: Space Situational Awareness SaaS: Software as a Service STM: Space Traffic Management TICAP: Trusted Internet Connection Access Provider. These are access points to the N-Wave network. TLE: Two Line Element. TLE is an orbit data format used by the United States Space Force to encode orbit elements at a particular epoch. URL: Uniform Resource Locator. A segment of text identifying a location of a resource such as a web page or data file in a network, commonly referred to as a - link. VCM: Vector Covariance Message. VCM includes a precision state vector and accompanying covariance (in equinoctial elements), along with amplifying OD data. The covariance portion of the message is variable sized (from 6 x 6 to 10 x 10), depending on which model parameters are solved for. XML: eXtensible Markup Language. A data storage and transmission format, popular with web application in recent decades, as well as the parent data format for HTML, one of the three languages used to create modern web pages, along with CSS and JavaScript. 1.2 References SPD-3 Space Policy Directive-3, National Space Traffic Management Policy CCSDS 508.0-B-1 Conjunction Data Message CCSDS 502.0-B-2 Orbit Data Messages CCSDS 503.0-B-2 Tracking Data Message CCSDS 922.2-B-1 Cross Support Transfer Service- Tracking Data Service 1.3 Background The OADR is the Department of Commerce's enterprise solution for ingesting, archiving, processing, and disseminating SSA data and products. OADR provides conjunction analysis and warning services to commercial satellite owner/operators to foster economic growth and technological advancement of the U.S. commercial space industry. The system will store data from the Department of Defense, Department of State, NOAA NESDIS, commercial SSA data providers, commercial and civil satellite Owner/Operators (O/O), and select international civil partners. The OADR system will operate 24 hours per day, 7 days a week. The Government may acquire an integrated PaaS environment, together with associated services, for open data and development where the OADR can reliably service its producers and customer base. The Government is conducting market research to identify current commercial capabilities to support the OADR's infrastructure based on the NIST Cloud Model. The Department of Commerce, through its Office of Space Commerce, is beginning the process of transitioning the commercial space situational awareness mission from the Department of Defense to the Department of Commerce, including the unclassified space object catalog. This unclassified catalog and associated data products need hosting in an appropriate cloud environment, along with the software needed to perform conjunction analysis on all objects in the catalog. Consumers and Producers of these data products, hereafter called the - Customer, includes US Govt. agencies, commercial space companies, the international community, academia, and citizen scientists. This RFI seeks to explore the current state of the market for cloud environment compute and storage services, data integration and data management services. In this context, data integration includes both integration with internal and external data sources/sinks. (See 4.0 Considerations and Constraints for a description of OADR external interfaces) The OADR software system used to perform orbit determination, ephemeris generation, conjunction screening, and conjunction response is excluded from the scope of this RFI. However, it is expected that the OADR software system will run in the cloud environment provided by the vendor and/or a GFE cloud environment. The OADR may have a hybrid architecture with compute, display, and short-term storage in the cloud and long-term data archive on-premises at an OADR data center. The following locations are being considered for the OADR data center: USSF - such as the 19th SPCS at Dahlgren Naval Base. This will be the likely location for the OADR to interface with the USSF High Accuracy Catalog and other Space Data products. Corporate NOAA Site - such as Suitland, some staffing possible Backup Site - such as Fairmont Consolidated Backup Utility, warm standby, no staffing Public Facing - for the public consumers and producers The OADR will have real-time communication feeds from various government agencies, which may be provided by NOAA's N-Wave. The cloud environment shall provide data processing services and possibly management services. This infrastructure layer within the cloud is often designated as the IaaS. As necessary some PaaS and SaaS services, integrated into the IaaS, need to be included in the response, i.e., management services. 1.4 Purpose The second decade of the 21st century has brought tremendous growth to the satellite industry, resulting in a large increase of commercial satellites in orbit. The 18 SPCS is finding its SSA/STM mission focused more and more on managing commercial objects, tracking approximately 5,000 active satellites and over 20,000 debris objects. These numbers are expected to continue to increase for the foreseeable future. The OADR project is in its nascent stage. Capacity planning of the entire system is at a rough order of magnitude (ROM) level prior to this RFI and is focused on general capacities for the Infrastructure as a Service (IaaS) which is part of the NIST Cloud Definition, NIST SP800-145, that addresses 1) Essential Characteristics, 2) Service Models, and 3) Deployment Models. 2.0 Cloud Products of Interest For Section 2.0 questions, assume that the IaaS layers are Network, Compute, and Storage. The OADR is expected to use N-Wave and TICAP services for its network portion. The need for data integration across multiple sources of space data from across the world's platforms and services will become increasingly crucial to SSA and STM, and the OADR's Initial Operating Capability will have similar functionality as Space-track's - Basic Services. 2.1 Cloud Deployment NIST has defined four cloud deployment models, 1) Private Cloud, 2) Community Cloud, 3) Public Cloud, 4) Hybrid Cloud. Given that we have Government, Military, Public, and Private needs to access this data, please describe how your system enhances the Hybrid Cloud experience. 2.2 Compute Architecture What do you recommend as a compute architecture for the OADR? What CPU and GPU services do you offer and how are these auto-scaled? Does your solution support containers? 2.3 Storage Systems The three primary types of cloud storage are block storage, file storage, and object storage. How would you recommend utilizing these storage types in the OADR? 2.4 Sandbox Concepts As part of data research, OADR customers may need the capability to leverage available APIs for research purposes. Please suggest approaches that enriches customer engagement tools and access (i.e. Containers, SNAP, Installatron, Jupyter Notebook). 3.0 Service Delivery, Integration, PaaS, IaaS, Orchestration & Technology Roadmaps 3.1 Licensing, GSA Schedule & Vendor Lock-In Considering the objective of keeping portability of products and services between different commercial vendors, what is your suggestion on proprietary vs. open-source product mix? 3.2 High Availability OADR will be a high availability system. Please provide your approach to achieving high availability, and your estimated availability in downtime minutes per year. Also, please provide your approach to data replication across multiple data centers. No single data center should result in loss of availability. 3.3 Future of Cloud Architecture Which parts of the cloud architecture are evolving into a newer model? And what do you envision as that newer model? What does the respondent envision for hosting and providing services for the evolution of the OADR roll-out? 3.4 Engineering Support v. Integration Please explain the differences between Engineering Support and Integration. 3.5 Integration of Services into IaaS Optional. How can you expand selected services for integration into IaaS? 3.6 Showcase Your portfolio Optional. You may showcase aspects of your portfolio as may be relevant to this requirement, OADR, or OSC's mission. 4.0 Considerations and Constraints Please list and explain if your service is unable to comply with these government considerations and constraints. In particular, please address cybersecurity compliance. How can the Government validate that compute and storage are performed in the United States? Which similar US Government systems have your capabilities supported in the last five years? Government Provided Services NOAA N-Wave for transport to the various nodes, NOAA Cyber Security Layer - encompasses CISA's National Cybersecurity Protection Service (NCSP) including Trusted Interface Connection (TIC) NIST Special Publications 500-332, The NIST Cloud Federation Reference Architecture 800-53 Revision 5 (or current) - Security and Privacy Controls for Information Systems and Organizations 800-145 The NIST Definition of Cloud Computing Government Policies Cybersecurity & Infrastructure Security Exchange https://www.cisa.gov/infrastructure-security Continuity of Operations Planning (COOP) - U.S. DHS FEMA Federal Continuity Directive 1 Issue Date: January 17, 2017 https://www.fema.gov/pdf/about/org/ncp/coop_brochure.pdf FEDRAMP Authorized Cloud Service providers https://fedramp.gov FCC Telecommunications Service Priority (TSP) https://www.fcc.gov/general/telecommunications-service-priority 5.0 External Interfaces DOD (19th Space Control Squadron): NASA (CARA) US Commercial Satellite Owner/Operators US Government Satellite Owner/Operators International Satellite Owner/Operators Other SSA Centers Commercial SSA Providers Space Weather Centers (NASA, NOAA, etc.) 6.0 Design Constraints 6.1 Logical Data Requirements 6.1.1 Metadata database The OADR shall include a metadata database to track all inputs/outputs and results from ephemeris generation, conjunction screening, and detailed conjunction analysis. Metadata shall include location of input and output files. 6.1.2 Immutable Data Create and read only, no update or delete. Data can be errata'd while preserving the originals 6.1.3 Files and file type standards All data files ingested and produced by the OADR shall conform to the appropriate standard format. VCM CCSDS OEM ephemeris CDM CCSDS Tracking Data Message (observations) 6.2 Data exposed All data ingested and produced via APIs or message queue shall conform to the appropriate standard 6.3 Data must be appropriately secured In transit At rest 6.4 Fine-grained access control OADR shall have access control based on contracts and data sharing agreements (policy as code). 6.5 System architecture makes appropriate use of storage technology OADR shall optimize storage based on expected workloads to minimize storage costs. Specifically, OADR shall favor technologies that can use object storage, and reserve block storage for operating system files, caches, and metadata. OADR shall prefer lower-cost storage environments for data-intensive workloads. 6.6 Support standard use cases Request-response (synchronous via API) Publish-subscribe (asynchronous via message bus) Bulk delivery 6.7 Data ingest/integration 6.7.1 Bulk integration The OADR shall be capable of ingesting large amounts of data using batch processing from many files and file types including TLEs, VCMs, OEMs, and observations. All batch data ingested must conform to the appropriate standard format. 6.7.2 Stream integration The OADR shall be capable of near real-time data ingest from external sources. All near real time data ingested must conform to the appropriate standard format. 6.7.3 Data management OADR platform shall include capability to manage Data Preparation Data sources Data monitoring (events, faults) Notifications 6.8 Support diverse data sets OADR shall support diverse data sets including Files Structured data (relational database) Documents Graphs 6.9 Discovery OADR shall include a mechanism for human users and machines to discover data and services. 6.10 Fair Data Principles To the extent feasible within budgetary and schedule constraints, OADR shall conform to FAIR principles to enable machine-enabled data mining and research. Specifically, OADR data shall be Findable, Accessible, Interoperable, and Reusable as documented in Wilkinson, M., Dumontier, M., Aalbersberg, I. et al. The FAIR Guiding Principles for scientific data management and stewardship. Sci Data 3, 160018 (2016). https://doi.org/10.1038/sdata.2016.18 Response Instructions Responses are due no later than 4:00 pm EST on August 18, 2022. Late submissions will not be accepted or reviewed. In order to ensure timely response and consideration of your feedback, we ask each company to limit itself to one (1) response. Please submit all responses to this RFI via Google Forms using the link below: https://docs.google.com/forms/d/e/1FAIpQLSeNNJ1rXJir_KVYq21m1QOjaSaWbq8nSqExZ0IoOQaTHg0S5A/viewform It is highly recommended that respondents draft their responses outside of the Google Form and then copy and paste responses into the form to avoid loss of data. If you are unable to access Google Form, you may submit your response via using the attachment "OADR Cloud RFI - Questions for Industry.xlsx". There are no character limits associated with Google Form. When providing multiple responses within a question, please start a paragraph for each response (i.e. click "enter" twice). Responders will automatically receive a copy of their response from "Google Forms". USE OF RESULTS AND CONFIDENTIALITY This RFI does not guarantee that the Government will issue a solicitation or award a contract for supplies or services. No specific solicitation is planned to follow this RFI; however, the responses could impact the Government's decision to release solicitation(s) in the future. Proprietary information will be safeguarded in accordance with the applicable government regulations. Any material received will be public domain unless clearly marked (on each page) as proprietary. The Government shall not be liable for or suffer any consequential damages for proprietary information not properly identified. Not responding to this RFI will not preclude an entity from submitting a proposal to any subsequent NOAA solicitations. Please email your questions or comments regarding the RFI to Jane Bu (Contract Specialist) at jane.bu@noaa.gov and Gion Lalican (Contracting Officer) at gion.lalican@noaa.gov. Respondents are advised that questions, comments and Government responses may be posted publicly on SAM.gov, although the identity of the requesting organization will be withheld.