A.1 On-Premise Capacity as a Service (CaaS) - PWS - Working Draft - MRR Final.pdf

M00264-26-RFI-003

Draft Performance Work Statement – Capacity as a Service (CaaS)

1.0 Introduction

The Marine Corps Installations Command (MCICOM), G-6 Installation Services Branch (ISB), seeks to acquire Capacity as a Service (CaaS) to support its Research, Development, Testing, and Evaluation (RDT&E) core infrastructure, laboratory environments, and data centers. CaaS is defined as an agile, on-demand, on-premise solution that delivers scalable computing, networking, and storage resources tailored to mission requirements across a variety of systems and applications.

2.0 Background

In alignment with the Data Center Optimization Initiative (DCOI), which mandates the reduction of data center footprints and the enhancement of Information Technology (IT) efficiency across Federal agencies, ISB is implementing a CaaS model to modernize its hosting capabilities. The DCOI emphasizes cost reduction, improved cybersecurity, adoption of best practices, and increased energy efficiency.

As a provider of IT solutions to the Department of Defense (DoD) and Department of the Navy (DoN), ISB requires a flexible and responsive infrastructure that supports dynamic project needs. The CaaS solution will enable ISB to rapidly provision infrastructure for new initiatives, scale resources to meet evolving demands, and decommission capacity when no longer required—thereby optimizing resource utilization and cost-effectiveness.

The selected CaaS solution must deliver timely, scalable, and cost-efficient computing, networking, and storage capabilities at Government-specified locations, ensuring operational readiness and mission alignment.

3.0 Scope

The Contractor shall furnish an on-premise Capacity as a Service (CaaS) by delivering and installing compute, networking, and storage hardware at designated Government facilities in support of ISB-managed networks and data centers. Refer to Section 8.0 – Contract Information for the list of supported locations.

Under this contract, the Government shall have the ability to request discrete, fit-for-purpose hardware capabilities from a catalog of vendor-provided offerings. Pricing shall be structured per hardware unit (e.g., per switch, server, or storage device). Upon order, the Contractor shall deliver, rack, and prepare the specified hardware for Government use. Operational control of the equipment shall transfer to the Government upon installation and acceptance.

The Government reserves the right to scale services up or down at any time by submitting new orders or deactivating existing ones. Billing terms and conditions are defined in Section 8.0 – Contract Information.

This requirement does not constitute a Cloud or Infrastructure as a Service (IaaS) contract. The Government retains full operational management of all delivered capacity. The Contractor shall be responsible for the procurement, delivery, installation, de-installation, and lifecycle maintenance of all hardware. Equipment shall be delivered as bare-metal systems, without pre-installed operating systems or virtualization layers. Embedded firmware or feature licenses necessary for hardware functionality may be included. All equipment must conform to the form, fit, and functional specifications outlined in the applicable Delivery Order (DO). Refer to Section 10.0 for Service Level Agreement (SLA) requirements.

4.0 Hardware and Software Interface Requirements

The Contractor shall furnish platform hardware (host/server systems) capable of supporting the Operating Systems (OS) specified in Table 4.0. While the OS itself is not a deliverable under this contract, all platforms must be fully compatible with the listed OS environments and associated interface protocols.

Table 4.0 – Platform Compatibility and Interface Requirements

Platform Type Supported Operating Systems Required

Interfaces

X86_64 CPU Windows Server, Red Hat Linux, SUSE Linux Enterprise Server, Solaris, VMware vSphere Enterprise Plus

FC, FCoE, 10/40 GbE

Itanium CPU HP-UX FC, FCoE, 10/40 GbE

SPARC CPU Solaris FC, FCoE, 10/40 GbE

IBM AIX AIX FC, FCoE, 10/40 GbE

NAS Must interface with all listed CPU platforms FC, FCoE, 10/40 GbE

SAN Must interface with all listed CPU platforms FC, FCoE, 10/40 GbE

Note: The Government reserves the right to request emerging or specialized capacity types not listed above (e.g., hardware accelerators, next-generation interconnects, disaggregated memory/storage architectures) as they become commercially viable and mission-relevant. Any such additions shall be proposed and approved via separate Delivery Orders (DOs).

5.0 Performance Requirements

The Contractor shall deliver modular, enterprise-grade capacity solutions to support Government data center operations. These solutions shall include compute, storage, and network hardware components, each provided as discrete, scalable units capable of seamless integration into existing Government-managed environments without service interruption.

All capacity types shall meet the following baseline performance criteria:

• Be physically delivered, racked, and made operational on Government premises

• Include enterprise-class features appropriate to their function (e.g., high availability, fault tolerance, virtualization support)

• Be modular and vendor-agnostic, enabling incremental scaling without requiring wholesale replacement

• Support non-disruptive configuration changes and capacity adjustments where feasible

• Integrate with existing physical and virtual infrastructure across compute, storage, and network domains

• Comply with applicable DoD standards for cybersecurity, data protection, and system interoperability

Detailed requirements for specific capacity types are outlined in Sections 5.1 through 5.7.

5.1 Enterprise Storage Capabilities

The Contractor shall provide high-availability, modular storage hardware solutions designed to meet mission-critical performance, scalability, and resiliency requirements. These solutions must be suitable for Tier I and Tier II data center environments supporting virtualization, application hosting, analytics workloads, and long-term data retention.

5.1.1 Required Capabilities:

• Multi-controller architecture with active-active data access paths

• RAID-based data protection, including support for advanced configurations (e.g., RAID 10, RAID 6, parity-optimized schemas)

• Logical storage pooling, thin provisioning, and non-disruptive scalability

• Replication features including synchronous, asynchronous, snapshot, and point-in-time copy support

• Automated data tiering based on performance and usage policies

• Compatibility with heterogeneous environments (Windows, Linux, VMware, UNIX)

• Support for Fibre Channel (FC), FCoE, and other standard SAN interconnects

• Data-at-rest encryption compliant with FIPS 140-2 or FIPS 140-3, validated through NIST’s Cryptographic

Module Validation Program (CMVP)

• Secure data sanitization in accordance with NIST SP 800-88 Rev. 1

• Support for logical units (LUNs), NVMe namespaces, or equivalent constructs ≥50TB, with total raw system capacity ≥6PB

• Optional support for read/write mirroring across geographically dispersed systems

• Data deduplication and compression features to optimize capacity and reduce replication overhead

• Support for shared multi-tenancy environments, where applicable

All systems shall be vendor-neutral, scalable, and interoperable with existing Government infrastructure.

Performance tiers (e.g., high-throughput/high-IOPS vs. high-capacity configurations) shall be available upon request to meet specific mission requirements.

5.2 Network Attached Storage (NAS) Capabilities

The Contractor shall provide modular NAS solutions designed to support high-performance file sharing, scalable unstructured data storage, and general-purpose data access across both virtualized and traditional server environments.

5.2.1 Required Capabilities:

• Support for NFS (v3 and v4.1) and CIFS/SMB protocols

• Verified compatibility with Windows, Linux, VMware, and UNIX clients

• Confirmed support for VMware vSphere datastores, including required locking and concurrency mechanisms

• Multi-VLAN support and tenant-level resource segregation

• Thin provisioning and non-disruptive capacity expansion

• RAID protection with node-level fault tolerance

• Snapshot, point-in-time replication, and asynchronous/synchronous copy features

• Secure deletion compliant with NIST SP 800-88 Rev. 1 or equivalent standards

• Data-at-rest encryption compliant with FIPS 140-2 or FIPS 140-3, validated by NIST’s CMVP

• Support for mid- to high-performance storage media, including SSD, SAS, and high-capacity SATA

• High-availability clustering support for NAS controllers

• Scalability to 50+ front-end ports supporting 10GbE or greater for NFS/SMB traffic

• Support for individual volume sizes ≥300TB

NAS solutions shall be modular, scalable, and suitable for a range of use cases including archival storage, VMware data stores, user file hosting, and backup target repositories.

5.3 SAN Switching and Fabric Capabilities

The Contractor shall provide enterprise-grade SAN switching solutions that are modular, scalable, and suitable for high-performance data center environments.

5.3.1 Required Capabilities:

• Director-class SAN chassis with redundant power supplies and support for multiple switching blades

• Hardware and/or OEM software enabling integration of four or more SAN directors into a unified managed fabric

• Switching blades with ≥48 ports, supporting speeds of 8 Gbps or greater (16 Gbps preferred)

• Fixed-port SAN switches with appropriate port densities and speeds for mid-scale deployments

• Management software for zoning, performance optimization, health monitoring, and fabric diagnostics

• Compatibility with Government-installed storage arrays and compute platforms

• Full support for VMware ESXi environments, including VMFS-backed shared storage over Fibre Channel

• Support for VMware multipathing configurations (e.g., Round Robin, Fixed, Most Recently Used), compliant with VMware’s Hardware Compatibility List (HCL) and best practices

5.4 General Hardware and Delivery Requirements

The Contractor shall deliver hardware-based capacity solutions—including compute, storage, and network components—that are fully integrated, scalable, and capable of installation and operation on Government premises without service disruption.

5.4.1 Physical Design and Redundancy Requirements:

• Rack-mounted or blade-based systems compatible with standard 19” data center racks

• Modular architecture allowing flexible ordering of individual components (e.g., switches, servers, blades)

• Redundant, hot-swappable power supplies and fans to minimize downtime due to hardware failure

• Support for multi-tenancy and logical resource separation where applicable

• Compatibility with standard interconnect protocols including Ethernet, Fibre Channel, and FCoE

5.4.2 Operational and Management Capabilities:

• Support for remote management interfaces (e.g., IPMI, iDRAC, iLO, or equivalent)

• Non-disruptive capacity changes and firmware updates, where supported and required

• High-availability ratings: enterprise-class systems targeting ≥99.999% uptime; all others ≥99.95%, exclusive of scheduled maintenance

• Secure out-of-band console access (e.g., Serial over IP, KVM-over-IP), with authentication controls and encrypted management traffic where applicable

• Optional intelligent power management features (e.g., monitored/switched PDUs) upon Government request

• Integration support for remote power control solutions for out-of-band operations

5.4.3 Cabling Standards and Documentation:

• All cabling shall be clearly labeled at both ends per industry best practices and Government naming conventions

• Labels must include destination port, equipment identifier, and circuit designation; they must be durable, legible, and resistant to environmental degradation

• Post-installation documentation shall include cabling diagrams and rack elevation summaries

• Cable routing shall follow professional data center standards to ensure airflow, accessibility, and maintainability

• Cables must be bundled, secured, and routed using appropriate cable management hardware; loose or obstructive cabling is noncompliant

• Rack doors must close and lock without obstruction

5.4.4 Installation and Physical Media Retention:

• Physical installation shall be performed by the Contractor; logical configuration shall be performed by the Government unless otherwise agreed in writing

• All storage media shall be handled in accordance with the requirements in Section 6.0 – Media Control.

5.4.5 Optional Environmental Monitoring Components:

At the Government’s request, the Contractor may provide environmental monitoring components (e.g., appliance servers for power management, cabinet telemetry systems) that directly support the operation, safety, or monitoring of ordered capacity.

5.4.6 Licensing and Subscription Scope:

• Hardware-based solutions may include feature licenses required for core functionality (e.g., HA clustering, secure boot, base encryption modules); these shall be included with the base offering

• No subscription-based software services (e.g., threat feeds, DPI engines, AI toolkits, software-defined storage platforms) shall be provided unless explicitly priced and ordered via Delivery Order (DO)

• The Contractor shall identify all included feature licenses and document activated functions upon delivery

• OEM support entitlements (e.g., firmware updates, diagnostics, security patches) are considered part of the hardware lifecycle and are not restricted by this clause.

5.4.7 Installation Scheduling and Decommissioning:

• Standard installation hours: 0600–1800 local time, Monday through Friday

• Off-hours or weekend installation shall be supported upon Government request

5.5 Compute Hardware Capabilities

The Contractor shall provide physical compute capacity across multiple performance tiers to support a broad range of workloads, from basic services to memory-intensive enterprise applications.

5.5.1 General Requirements:

• Compatibility with common virtualization platforms (e.g., VMware vSphere, Microsoft Hyper-V, KVM)

• Support for booting from local SSD or SAN-based storage

• All CPU cores presented to the operating systems shall offer consistent instruction set support and performance characteristics suitable for virtualized and compute-intensive workloads

• Architectures utilizing heterogeneous core designs (e.g., performance vs. efficiency cores) may be evaluated for workload compatibility

5.5.2 Indicative Capacity Tiers (non-prescriptive):

Tier Configuration Entry Tier Dual-socket, multi-core CPU systems with 32–64GB RAM Standard Tier Dual-socket, multi-core CPU systems with 128–256GB RAM High Memory Tier Dual- or quad-socket systems with 512GB–1TB+ RAM

Specialty Tier Configurable systems with GPU acceleration, high core count, or optimized for AI/ML workloads

5.5.3 Specialty Tier Requirements:

• GPU-accelerated compute nodes compatible with CUDA (e.g., NVIDIA A100, H100, L40S, L4)

• High-speed interconnects such as PCIe Gen5, NVLink, or InfiniBand

• NVMe-based local storage for low-latency, high-throughput access

• Enhanced power and cooling configurations for high-density deployments

• Compatibility with Government-supplied AI/ML software stacks (e.g., PyTorch, TensorFlow)

All compute nodes shall support a minimum of three functionally segregated and redundant network paths (e.g., management, storage, public traffic), implemented via discrete NICs or bonded interfaces as appropriate.

5.6 Network Hardware Capabilities

The Contractor shall provide enterprise-grade and mid-tier networking hardware to support scalable, high-performance data center connectivity.

5.6.1 Required Capabilities:

• Modular and fixed-port switches supporting 10/25/40/100GbE as applicable

• Core and aggregation switches with high availability, stacking, or clustering support

• VLAN tagging, link aggregation, port mirroring, and Quality of Service (QoS) policy enforcement

• Compatibility with Government Layer 3 routing and segmentation practices

• Optional support for hardware-based encryption and deep packet inspection (if requested)

• Delivery of all required optics, transceivers, and cabling per physical design specifications

5.6.2 Advanced Networking and Security Components (as required):

• Fabric Extenders (FEX) for scalable top-of-rack port expansion under centralized control

• Next-Generation Firewalls (NGFW) with application-layer inspection, intrusion prevention, SSL/TLS decryption, and policy-based controls

• Network Access Control (NAC) appliances/modules supporting device posture assessment and integration with identity stores (e.g., Active Directory, LDAP)

• Application Gateways or virtual appliances for Layer 7 load balancing, reverse proxy, and traffic routing

• Web Application Firewalls (WAF) providing real-time HTTP/HTTPS inspection and OWASP Top 10 protections

• Application Delivery Controllers (ADCs), such as F5 BIG-IP or equivalent, supporting SSL offloading, health monitoring, and advanced traffic management

All devices shall be compatible with the Government’s network architecture and zoning models and may be deployed inline or in service-chained configurations. Solutions shall include all required cabling, optics, rack components, and installation support. Software subscriptions shall be scoped separately unless explicitly ordered.

5.7 Interoperability and Integration Support

All Contractor-provided infrastructure shall be interoperable with existing Government platforms and environments.

5.7.1 Required Capabilities:

• Compatibility with current chipsets, operating systems, and virtualization stacks as defined in Table 4.0

• Dual-stack IPv4/IPv6 support in conformance with DISR standards and vendor documentation

• Hardware-based health monitoring and threshold alerting via local interfaces (e.g., IPMI, Redfish, SNMPv3)

• Installation of cloud-connected monitoring agents, OEM telemetry software, or remote diagnostic utilities that transmit data off-premises is strictly prohibited

The Contractor shall coordinate with Government personnel during onboarding to validate compatibility, perform integration testing, and provide connection specifications as required.

5.8 OEM Support Access and Escalation Paths

The Contractor shall maintain active Original Equipment Manufacturer (OEM) support contracts for all hardware and components delivered under this contract for the full duration of their operational lifecycle at Government facilities. OEM support shall include:

• 24x7 access to vendor technical assistance

• Access to firmware updates and security patches

• Eligibility for part replacement and Return Material Authorization (RMA) services

• Maximum response time of five (5) business days for part replacement and issue resolution

Accelerated support tiers (e.g., 4-hour or next-business-day RMA) are preferred for high-availability systems but are not mandatory unless specified in the applicable Delivery Order (DO).

All OEM support interactions—including technical assistance, case management, and access to diagnostic data— shall be restricted to U.S. citizens located within the United States, unless prior written authorization is granted by the Government. The Contractor shall ensure that all vendor-provided support services comply with DoD security requirements and do not involve foreign nationals accessing Government systems, data, or equipment serial numbers.

If the Government is not authorized or elects not to engage directly with the OEM (e.g., Cisco, NetApp, Dell), the Contractor shall act as the designated support liaison. Responsibilities include:

• Responding to Government-reported issues

• Initiating and managing OEM support cases on behalf of the Government

• Relaying technical guidance, updates, and replacement instructions in a timely manner

The Contractor shall ensure that any required authentication credentials, access tokens, or serial number registrations necessary to access vendor documentation, firmware repositories, or case management systems are either:

• Provided directly to ISB personnel, or

• Actively managed by the Contractor with full Government visibility into support status and updates

No delivered capacity shall lapse into an unsupported state without prior written notification to the Government and an opportunity to renew or replace affected components. If OEM support for a component is discontinued (e.g., end-of-life or end-of-service), the Contractor shall notify the Government in writing no less than ninety (90) calendar days in advance and propose a plan for replacement, upgrade, or risk mitigation. No Sub-Line Item Number (SLIN) shall remain billable while in an unsupported state without written Government concurrence.

5.9 Capacity Lifecycle: Acceptance, Deactivation, and Removal

This section defines the requirements and criteria for Government acceptance of delivered capacity, as well as the conditions and procedures for deactivation and removal. These definitions apply to all ordering and delivery timelines in Section 10.0 and are used in conjunction with the billing provisions in Section 8.0.

5.9.1 Acceptance

The Government shall perform acceptance of delivered capacity within five (5) business days of confirmation that the equipment is physically installed and ready for use. Billing terms associated with acceptance are defined in Section 8.0 – Contract Information.

5.9.2 Deactivation

Deactivation is defined as the termination of service for a specific SLIN, independent of physical equipment removal. Billing terms associated with deactivation are defined in Section 8.0 – Contract Information. Refer to Section 10.0 for applicable Service Level Agreement (SLA) details.

5.9.3 Equipment Removal

Upon deactivation, the Contractor shall coordinate with the Government to schedule physical removal of the associated hardware from ISB facilities. Removal shall occur within thirty (30) calendar days of deactivation unless otherwise directed in writing. Equipment may not be abandoned or left onsite without Government authorization.

The Government reserves the right to deny removal access if the Contractor fails to comply with required sanitization, labeling, or logistics coordination protocols. All removal activities shall be logged and documented for accountability and inspection purposes.

5.10 Equipment Movement

Movement is defined as the relocation of equipment within the same Government facility. This may be required due to:

• Data center reconfiguration

• Power or HVAC outages

• Infrastructure upgrades

• Phase transitions

• Hot/cold aisle reconfigurations

• Natural disaster response

The Contractor shall support intra-site equipment movement as directed by the Government, ensuring proper handling, reinstallation, and documentation.

5.11 Technology Refresh

The Contractor is responsible for ensuring the provided capacity remains technologically current and does not become obsolete during the contract's period of performance. The Contractor's proposal shall describe their methodology and commitment for refreshing hardware that is approaching its end-of-support-life or is no longer performing at a level consistent with current-generation technology. At no point shall the Government be expected to pay for capacity on hardware that is more than 60 months past its original date of manufacture.

5.12 Engineering and Technical Support Services

The Contractor shall provide Engineering and Technical Support Services on an as-needed basis to assist the Government in maintaining and optimizing its operational infrastructure. These services may include support for the delivery, installation, relocation, configuration, integration, and troubleshooting of hardware and related systems within the Government’s IT environment.

All Technical Support Services shall be performed under separately priced Contract Line-Item Numbers (CLINs) and initiated only upon receipt of formal written authorization from the Contracting Officer (KO) or Contracting Officer’s Representative (COR). Each engagement shall be structured as a task-based, Firm Fixed Price (FFP) effort with a clearly defined scope of work.

5.12.1 Representative Technical Support Activities

Examples of authorized support activities include, but are not limited to:

• Hardware Relocation (Move): Deinstallation, transport, and reinstallation of Contractor-provided equipment within or between Government facilities, including power cycling and cabling adjustments.

• Hardware Reconfiguration: Modifications to rack layout, cable routing, or equipment placement to accommodate changes in facility infrastructure, electrical systems, or HVAC constraints.

• Installation Support: Execution of non-standard setup procedures such as RAID configuration, BIOS tuning, network uplink establishment, or integration into fabric or cluster environments.

• Integration Support: Assistance with onboarding delivered capacity into existing platforms, including virtualization environments, storage fabrics, or compute clusters.

• Troubleshooting Support: Hands-on technical assistance to identify, isolate, and resolve infrastructure-related faults or performance issues affecting supported capacity.

5.12.2 Software-Adjacent Infrastructure Support

Upon request by the Government, the Contractor may provide technical assistance for Government-owned platforms and applications (e.g., Citrix, Splunk, Windows Server, Linux, virtualization stacks) when such support is directly related to the integration, configuration, or operational readiness of infrastructure delivered under this contract. This may include:

• Resolving compatibility issues

• Performing initial configuration

• Assisting with capacity onboarding to ensure functional alignment within the broader IT environment

Support may also include diagnostic guidance or interoperability assistance for infrastructure-dependent software platforms. For example, integrating Citrix StoreFront with a Government-furnished F5 BIG-IP appliance in lieu of a NetScaler, provided such activity is necessary to activate or optimize ordered capacity.

The Contractor shall not assume ongoing operational responsibility for any application or platform. End-user support, software licensing management, and general-purpose system administration are explicitly excluded from the scope of Technical Support Services.

Preventive maintenance, software patching, release management, and long-term system administration are not authorized under this CLIN. No services shall commence without formal tasking, documented scope approval, and written authorization from the Contracting Officer (KO) or Contracting Officer Representative (COR). Informal, sales-driven, or verbally requested services shall not be initiated under this contract.

5.13 Logistics Coordinator

The Contractor shall designate a primary and an alternate Logistics Coordinator to serve as the Government’s single point of contact for all matters related to scheduling and coordinating site access for the performance locations identified in this PWS. The Coordinator is not required to be physically located at any Government site.

The responsibilities of the designated Coordinator shall include, but are not limited to:

• Serving as the central liaison between the Government and all contractor personnel, subcontractors, Value-Added Resellers (VARs), and delivery personnel requiring site access.

• Collecting and submitting all required security and visitor access documentation to the appropriate Government security office in accordance with site-specific procedures.

• Coordinating and scheduling all on-site activities, including initial hardware installation, maintenance visits, and end-of-service de-installation.

• Providing timely and proactive status updates to the Government regarding scheduled activities and any anticipated delays.

The cost associated with this coordination function shall be included in the Contractor’s proposed pricing for the required supplies and services. This function shall not be billed separately.

5.14 Meeting Requirements

The Contractor shall participate in recurring meetings with the Government to support contract execution, performance monitoring, and issue resolution. Required meetings include:

• Kickoff Meeting: Conducted shortly after contract award to establish scope, tasking procedures, and points of contact.

• Program Review Meetings: Held at least semi-annually, or more frequently upon request, to review delivery timelines, capacity utilization, SLA performance, risk factors, and future requirements.

• Ad Hoc Coordination: Additional meetings or teleconferences may be scheduled by either party to address emergent issues or tasking needs. All meetings shall be coordinated in advance and mutually agreed upon.

The Contractor shall ensure that appropriate technical and program personnel are available to participate in these meetings, as required by the agenda.

6.0 Security Requirements

The Contractor shall comply with all applicable Department of Defense (DoD), United States Marine Corps (USMC), and local site security policies governing physical access, information assurance, and the handling of media and equipment.

6.0.1 Media Control

All writeable storage media (e.g., hard drives, SSDs, flash memory, tapes) provided under this contract shall remain the property of the Government. No media shall be removed from Government facilities. Failed or decommissioned media shall be returned to the Government for secure destruction in accordance with DoD and ISB security protocols.

6.0.2 Prohibited Devices

In accordance with DoD CYBERCOM CTO 10-084, the use of USB flash/thumb drives is strictly prohibited. The Contractor shall ensure that such devices are not utilized in any operational processes.

6.0.3 Personnel Eligibility and Access

All Contractor personnel performing under this contract must:

• Be U.S. citizens

• Be escorted by authorized Government personnel while onsite, unless otherwise approved in writing

• Undergo identity verification and background screening appropriate to the facility’s security level

• Refrain from accessing Government systems, data, or storage media unless explicitly authorized

DISS registration or security clearance may be required for specific tasks involving classified environments or unescorted access, at the Government’s discretion.

6.0.4 Access Coordination

The Contractor shall coordinate all physical access to ISB-managed data centers with the designated site Point of Contact (POC) or Data Center Manager. Access shall be requested via Visit Authorization Requests (VARs) submitted through the Defense Information System for Security (DISS). Contractor personnel must comply with all entry/exit control procedures and wear appropriate identification while onsite.

6.0.5 Foreign Nationals

Foreign nationals are prohibited from accessing ISB facilities or information systems under this contract.

6.0.6 Security Training and Compliance

The Government shall provide initial and recurring security briefings. Contractor personnel must comply with all security protocols and may be removed from the facility or contract for violations.

6.0.7 Government Right of Removal

The Government reserves the right to request the immediate removal of any Contractor personnel whose conduct or performance is deemed inconsistent with mission requirements or the interests of the Government. Removal requests shall be documented by the COR and endorsed by the KO.

6.0.8 Classified Work and DD254 Requirements

Performance under this contract is not expected to involve classified information or systems by default. However, in the event that a specific Delivery Order (DO) requires access to classified material, systems, or facilities, the Government will issue a DD254 (Department of Defense Contract Security Classification Specification) to define the applicable security requirements.

If a DD254 is issued, the following conditions shall apply:

• The Contractor shall maintain a Facility Clearance (FCL) at the classification level specified in the DD254 throughout the applicable performance period.

• All personnel requiring access to classified information shall possess the appropriate clearance level (e.g., Secret, Top Secret, TS/SCI) as identified in the DD254. Interim clearances may be accepted at the Government’s discretion.

• Visit Authorization Requests (VARs) shall be submitted through the Defense Information System for Security (DISS).

• The Contractor shall designate a Facility Security Officer (FSO) responsible for coordinating all security matters with the Government Security Representative.

• Classified material handling, if required, shall comply with DoDM 5200.01, including:

o Use of GSA-approved storage containers o Secure communication channels (e.g., SIPRNet) o Authorized destruction methods (e.g., burn bags, disintegrators, cross-cut shredding)

• Personnel shall comply with DoDM 5200.02 reporting requirements, including:

o Adverse information reporting o Foreign travel notification and approval o Changes in personnel status affecting clearance eligibility

No work involving classified systems, data, or materials shall begin unless a valid DD254 is in place and approved by the Contracting Officer (KO).

7.0 Transition Strategy

The Contractor shall support both the initial onboarding of services and the orderly transition of responsibilities at contract conclusion. All transition-related activities shall be documented and submitted in accordance with the Contract Data Requirements List (CDRLs) defined in Section 9.0, specifically:

• CDRL A003 – Onboarding Transition Strategy

• CDRL A004 – Offboarding Transition Strategy

7.0.1 Onboarding Transition Plan (CDRL A003)

Within fourteen (14) calendar days of contract award, the Contractor shall submit a comprehensive Onboarding Transition Strategy. This plan shall include:

• Projected delivery and installation timelines for the initial Delivery Order (DO)

• Sequenced steps for hardware capacity onboarding

• Site-specific coordination and access requirements

• OEM support activation procedures

• Designated points of contact for Contractor and Government coordination

The Government shall review and approve the plan prior to execution. No onboarding activities shall commence without written approval.

7.0.2 Offboarding and Contract Closeout Plan (CDRL A004)

No later than ninety (90) calendar days prior to the conclusion of the final period of performance, the Contractor shall submit a draft Offboarding Transition Strategy. The plan shall include:

• Inventory of all active SLINs and installed hardware

• Status of open support tasks and pending deactivations

• Decommissioning and equipment removal procedures

• Documentation turnover and badge return protocols

• Coordination timeline for final Government acceptance

The final version shall incorporate Government feedback and serve as the authoritative roadmap for service termination or transition to follow-on efforts. The Contractor shall maintain continuity of service through the end of the contract.

8.0 Contract Information

8.0.1 Contract Type and Pricing Model

The Government is conducting market research to understand potential contract and ordering approaches that could support the delivery of hardware-based capacity under a Capacity as a Service (CaaS) model. As part of this effort, the Government is seeking industry feedback on feasible methods for structuring unit-based pricing, ordering, and lifecycle management for compute, storage, and network capacity.

Respondents are invited to provide input on approaches that could support recurring or as-needed ordering of capacity. This may include, but is not limited to, catalog-based pricing models, unit-based pricing structures, or other mechanisms commonly used in industry to support scalable hardware delivery.

Potential CLIN Structure (For Market Research Purposes Only)

The Government is seeking feedback on the feasibility of organizing deliverables in a structure similar to the following:

• Major categories of deliverables (e.g., Compute Hardware, Storage Hardware, Network Hardware, Technical Support Services) may be grouped at the CLIN level.

• Individual hardware units could be defined at the unit level for ordering, billing, and lifecycle tracking.

• Each unit-level deliverable would:

o Correspond to a discrete physical asset (e.g., server, storage shelf, network switch) that can be independently delivered, activated, and deactivated.

o Be uniquely identifiable and traceable from delivery through deactivation.

• Bundling, pooling, or partial billing of unit-level deliverables may require Government approval.

• For new capacity types or hardware models introduced over time, the Government is interested in understanding how industry typically provides pricing justification (e.g., commercial list pricing, catalog-based models, GSA schedule rates, or other verifiable benchmarks).

8.0.3 Potential Ordering Approach

The Government is seeking information on industry’s ability to support an ordering process for hardware-based capacity under a future requirement. For planning purposes, the Government anticipates that any future contract may require the Contractor to accept orders only when issued through an authorized written request from the Government.

A typical ordering action may include the following information:

• The item(s) being procured

• The unit type and quantity

• The delivery location(s) identified in Section 8.0.7

• The required delivery timeframe

• Any site-specific installation or access requirements

The Government is interested in understanding how industry typically manages order intake, validation, and authorization processes. Respondents may describe their standard practices for ensuring that no work, procurement, or shipment begins without a formal written order from the customer.

8.0.4 Pricing Model

Pricing shall be per unit, tied to a CLIN, and invoiced only for capacity explicitly ordered, delivered to the designated performance location, and formally accepted for use by the Government. Bundled services, unrequested overprovisioning, or pooled resource billing are prohibited.

8.0.5 Billing Lifecycle

• Acceptance: Billing shall commence upon formal Government acceptance of the delivered unit.

• Deactivation: Billing shall cease within three (3) business days of a Government-issued deactivation notice, regardless of when the unit is physically removed.

• No charges shall apply to unused or excess capacity beyond what was requested and accepted.

• All invoices shall reflect only the units and dates confirmed by the Government.

8.0.6 Invoice Requirements

• The Contractor shall operate on a standard monthly billing cycle, accommodating months of 28, 29, 30, or 31 days.

• Invoices shall be generated from contract order data maintained by the Government and shall include:

o CLIN and unit-level deliverable identification.

o Acceptance Date for each billed unit.

o Deactivation Date for any unit deactivated during the billing period.

• Draft invoices shall be submitted to the Government for review and approval prior to final submission and Payment processing.

• No invoice shall be considered valid without Government approval of the associated unit activity and billing details.

8.0.7 Funding, Equipment Ownership, and Data Media Retention

a. Funding Basis: This contract is funded under Operations and Maintenance (O&M) appropriations.

b. Equipment Ownership: Except as provided in paragraph (d) below, the Government will not take ownership of any hardware provided under this contract. To support flexible financing arrangements, including OEM-based leasing, all equipment furnished under this requirement shall remain the property of the Contractor and/or the Original Equipment Manufacturer (OEM). The equipment is provided solely as an operational capability for the duration of its use. Regardless of ownership or financing arrangements, the Contractor remains fully responsible for meeting all requirements, terms, and conditions of this PWS.

c. Contractor Responsibility for Equipment: The Contractor is responsible for all costs associated with providing, maintaining, and removing its equipment. The Government will not be liable for loss or damage to contractor-owned property, except to the extent such loss or damage results from the gross negligence or willful misconduct of Government personnel.

d. Government Ownership of Data-Bearing Media: Notwithstanding paragraph (b), all writable storage media that has ever contained Government data shall become the property of the Government.

• This requirement applies to all such media, including but not limited to Hard Disk Drives (HDDs), Solid-State Drives (SSDs), and NVMe devices.

• Ownership transfers to the Government immediately upon component failure or upon de-installation of the parent device.

• The Contractor is prohibited from removing such media from a Government facility for any purpose, including warranty claims, failure analysis, or return to a leasing entity.

• The Contractor’s pricing shall account for this media-retention requirement, and the Contractor shall bear all associated costs, including any impacts to OEM warranties or lease-return obligations.

8.0.8 Pricing for Future Requirements

To support potential future ordering needs under this requirement, the Government may establish a pricing approach for items not included in the Representative Bill of Materials (BOM). If implemented, this approach would allow the Government to order additional items efficiently throughout the period of performance. One possible method is the use of a fixed percentage discount from the Contractor’s published Commercial Catalog; however, the Government remains open to alternative pricing methodologies proposed by offerors that provide equal or greater flexibility and value.

Instructions for proposing a discount-based pricing method, along with the sample BOM used for evaluation purposes, are provided in Appendix A – Sample Bill of Materials for Pricing Evaluation.

8.0.9 Performance Locations

Hardware shall be delivered, installed, and made operational at the following Government facilities:

Location SMO Code Marine Corps Information Technology Center (MCITC), Kansas City, MO 660015 Newlin Hall, Marine Corps Base Quantico, VA 652366

8.0.10 Government Coordination and Oversight

A designated Contracting Officer’s Representative (COR) shall serve as the primary point of contact for order validation, capacity tracking, and coordination of acceptance and deactivation activities. The Contractor shall coordinate all site access, installation schedules, and issue resolution through the COR. The COR POC will be provided at time of award.

8.0.11 Contract Modifications and Extension Clause

This contract may be modified by mutual agreement to accommodate emerging capacity requirements, including new hardware types or advanced compute capabilities (e.g., AI accelerators, edge devices). The Government reserves the right to exercise option periods or issue a follow-on contract to extend or evolve service delivery based on operational needs and Contractor performance.

8.0.12 Period of Performance

The contract shall consist of:

• One (1) year Base Period

• Four (4) one-year Option Periods

9.0 Deliverables

CDRL # Deliverable Frequency Reference A001 Monthly Capacity Order & Status Report Monthly PWS 10.3 A002 SLA Compliance Summary Quarterly PWS 10.3

CDRL # Deliverable Frequency Reference A003 Onboarding Transition Strategy Within 2 weeks of award PWS 7.0.1 A004 Offboarding Transition Strategy 90 days before contract end PWS 7.0.2 A005 Ordering Process Description Within 2 weeks of award PWS 8.0.3 A006 Ad-hoc Reports (as requested by ISB) As Required PWS 10.3

10.0 Service Level Agreement (SLA)

These SLAs apply exclusively to Contractor-controlled tasks related to hardware delivery and lifecycle management. They do not extend to network uptime, system performance, or application availability, which are managed by the Government post-acceptance.

10.0.1 Ordering and Delivery Timelines

Ordering procedures are described in Section 8.0.3. The following timelines establish the Government’s expected delivery and installation timeframes for future ordering actions under this requirement:

• New Hardware Orders: Delivered, racked, powered, and confirmed “ready for use” within forty (40) business days of Government order acceptance, unless otherwise negotiated. The Contractor shall proactively notify the Government of any anticipated delays.

• Add-On Capacity (e.g., drives, memory, NICs): Delivered and installed within twenty (20) business days, subject to availability.

• Order Validation: The Contractor shall confirm order accuracy and availability within three (3) business days of receipt.

10.0.2 Incident Response (Delivery and Installation Phase)

• Acknowledgment of Delivery Issues: Within one (1) business day of Government notification.

• Corrective Action Implementation: Within three (3) business days of acknowledgment.

• Hardware Replacement (Defective on Arrival): Replacement parts shipped within five (5) business days of Contractor confirmation following Government notification.

10.0.3 In-Service Hardware Failure Response (Post-Acceptance)

Upon notification of a hardware fault (e.g., CPU, NIC, SSD, PSU, motherboard), the Contractor shall:

• Acknowledge the issue within one (1) business day

• Initiate diagnostic coordination with the Government and OEM

• Provide timely updates and corrective actions to restore service

10.1 OEM Validation, Replacement Coordination, and Degraded Capacity Management

10.1.1 OEM Validation and Liaison Responsibilities

OEM liaison responsibilities are defined in Section 5.8.

10.1.2 Replacement Delivery and Installation

Upon OEM approval of a hardware replacement, the Contractor shall ensure delivery and installation of the replacement component within five (5) business days, or as otherwise dictated by OEM part availability. The

Contractor shall coordinate all on-site replacement activities with the Government and confirm that the affected system is restored to “Ready for Use” status.

10.1.3 Billing Suspension for Inoperable Capacity

If a CLIN/SLIN is rendered inoperable and cannot perform its intended function, the Government may request suspension of billing for the affected CLIN/SLIN until full functionality is restored. The Contractor shall not be penalized for delays attributable to documented OEM investigation timelines but is expected to pursue resolution with reasonable urgency.

10.1.4 Lifecycle Refresh and End-of-Support Mitigation

The Government reserves the right to require refresh or replacement of any CLIN/SLIN that:

• Has exceeded five (5) years in service, or

• Is no longer supported by the OEM

If the Contractor cannot propose a replacement or mitigation strategy acceptable to the Government, the CLIN/SLIN may be deactivated and removed from billing.

10.1.5 Degraded Capacity Exception

The Government may declare a CLIN/SLIN non-functional if hardware degradation materially impacts usability, even if the component remains technically operational. Examples include:

• Persistent failover behavior

• Performance throttling

• Unrecoverable fault conditions affecting availability or predictability

Upon notification and verification, the Contractor shall coordinate remediation or replacement. Billing may be suspended for the affected CLIN/SLIN until performance is restored to acceptable levels.

10.2 Force Majeure and Catastrophic Events

In the event of a catastrophic incident affecting one or more performance locations (e.g., natural disaster, fire, flood, terrorism, or other force majeure event), the Government may suspend billing for impacted capacity effective the date of the incident. The Contractor shall:

• Notify the Government within five (5) business days of the event

• Make reasonable efforts to resume service or coordinate recovery actions

Resumption of service, equipment replacement, or related recovery efforts shall be addressed via modified Delivery Orders (DOs) or separate tasking, as appropriate. The Contractor shall not be held liable for SLA violations or delivery delays directly resulting from such events, provided timely notification and good-faith recovery efforts are demonstrated.

10.3 SLA Monitoring and Compliance

Service Level Agreement (SLA) compliance shall be monitored through the following deliverables:

• CDRL A001 – Monthly Capacity Order & Status Report

• CDRL A002 – SLA Compliance Summary Report

Repeated or unresolved SLA violations may result in formal notice from the Contracting Officer’s Representative (COR) and may impact:

• Future Delivery Orders (DOs)

• Contract extension decisions

• Performance evaluations

If the Contractor incurs three (3) or more unresolved SLA violations within a six-month period, the Government may impose additional oversight requirements, suspend future tasking, or decline to exercise option periods.

11.0 Other Pertinent Information and Special Considerations

11.0.1 Facility Support

The Government shall provide the necessary facility infrastructure to support Contractor-provided hardware, including:

• Floor space

• Power and HVAC

• Uninterruptible Power Supply (UPS) connectivity

The Contractor shall coordinate all physical installation requirements—including power draw, rack layout, cabling routes, and environmental dependencies—with the COR prior to delivery. The Government shall not be responsible for providing specialized or proprietary infrastructure components beyond standard commercial-grade facility support.

All hardware installations must conform to applicable Government safety, cabling, and floor load guidelines.

12.0 Hours of Operation

12.0.1 Normal Business Hours

• 0600 to 1800 (local time), Monday through Friday, excluding Federal holidays.

12.0.2 After-Hours Support

• All other times, including weekends and Federal holidays, are considered After Hours.

Contractor activities such as deliveries, installations, or coordination that must occur outside of Normal Business Hours shall be scheduled in advance and approved by the COR and designated site Point of Contact (POC).