HC102817R0015_Amend0008_J-1_PWS_trackchanges.pdf

XSPCS SPSPARC PCS PWS

Attachment J-1

AMEND 00070008

PERFORMANCE WORK STATEMENT (PWS)

as of 28 July10 August 2017

Contract Number:

Task Order Number: (completed by the KO at time of TO award or N/A)

1.0 Contracting Officer Representative (COR).

a. Primary COR or TM. See Clause 52.204-9000

Name: Provided at award Organization: Provided at award Department of Defense Activity Address Code (DODAAC):

Provided at award

Address: Provided at award Phone Number: Provided at award Fax Number: Provided at award E-Mail Address: Provided at award

b. Alternate COR or TM. See Clause 52.204-9000

Name: Provided at award Organization: Provided at award Provided at award Provided at award Address: Provided at award Phone Number: Provided at award Fax Number: Provided at award E-Mail Address: Provided at award

2.0 Contract Title. DISA, Operations Center (OC), X86 and SPARC Compatible Processor Capacity Services

(XSPCSSPPCSSCPCS).

3.0 Background. DISA is a provider of information technology solutions for the Department of Defense (DoD).

Defense Information Systems Agency’s (DISA’s) DoD customers require processing for a variety of applications.

DISA must have the ability to provide cost-effective processing capacity in a timely manner whenever and wherever required.

DISA is required by the DoD to enhance information technology effectiveness through improved interoperability.

The Assistant Secretary of Defense for Networks and Information Integration (ASD/NII) has articulated a vision for transforming the information environment in the DoD. This vision calls for a move from the centralized thinking and planning currently reflected in the Task, Process, Exploit, Disseminate (TPED) paradigm, to an edge-centered Task, Post, Process, Use (TPPU) approach to information sharing and availability. The envisioned changes represent a fundamental paradigm shift from providing platform centric applications to platform independent, web-enabled, Net-Centric services requiring the support of a diverse processing environment, that meets the requirements of the end users, and which is highly available, secure, and reliable. As a result of the shift to Net-Centric services, DISA will also need to provide processing capabilities at DISA-owned and other approved processing locations.

4.0 Objectives. The objective of this contract is to obtain reliable, responsive, and cost effective processor infrastructure services of “on-demand” SPARC Compatible chipset processing capabilities for DISA and/or DISA-approved locations, located in both the continental United States (CONUS) and outside of the continental United States (OCONUS). DISA's goal is to obtain a dynamically scalable processing capability utilizing an on-demand service approach, for new equipment, that will readily adjust to changes in processing and throughput requirements, both increases and decreases, and is priced on a utility ("as used") basis or tiered structure.

The service provider will acquire, deliver, install, configure, deinstall, and provide the necessary hardware (which may include but is not limited to cabinets/racks/cabling/cable management/ power distribution units (PDUs)), hardware maintenance, operating system software, hypervisor solution, as well as, any other software required for the Contractor’s solution to operate, and services to support the processor infrastructure associated with this contract. The Government will maintain day-to-day operational control and complete oversight responsibility of the processing environment. This operational control includes the installation of all software updates after the initial delivery. However, all operating system software, hypervisor solution, as well as, any other software required for the Contractor solution to operate, including software maintenance and licensing shall be provided by the Contractor under this contract.

5.0 Scope. The Contractor will acquire, deliver, install, configure, and maintain SPARC Compatible chipset processor capacity infrastructure in concert with the Government, at any of the current DISA computing facilities or future DISA computing facilities in the continental US (CONUS), DISA outside CONUS (OCONUS) and other DISA or DISA approved locations worldwide where DISA may acquire an operational responsibility. The contract will provide capacity services on all equipment delivered under this contract (including options if exercised) until it is no longer required by the government.

5.1 The hardware/chipset and the operating systems software, required to deliver processor capability are listed below. Statements containing direct chipset references will only apply to their respective contracts.is SPARC Compatible (Solaris)

5.1.2 X-86 (Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Solaris, Oracle Enterprise Linux)

5.1.3 SPARC Compatible (Solaris)

5.2 All locations may require a NIPR and SIPR environment.

5.2.1 Unclassified and Classified Level Environments. Where required under this contract, the Contractor will provide engineering and maintenance support personnel with the appropriate clearance for DISA’s classified and unclassified environments. (See para 13 for individual personnel security requirements). The Contractor will deploy separate equipment for classified and unclassified environments and will provide all assets needed for the processor infrastructure regardless of environment (classified or unclassified).

5.3 The objective is for the Contractor to provide processor services using a “utility contract concept”. This utility concept requires that the Contractor provide all assets needed for the processor service. These assets shall include, but are not limited to, hardware, software, software maintenance licensing, design capabilities, logistical support, field maintenance, and systems engineering.

5.4 Current Environment – DISA currently provides processor services at multiple computing facilities in both the CONUS and OCONUS, including but not limited to:

5.4.1 CONUS locations:

o Columbus, OH o Fort Meade, MD o Mechanicsburg, PA o Montgomery, AL o Ogden, UT o Oklahoma City, OK o San Antonio, TX o St Louis, MO

5.4.2 OCONUS locations:

o Germany o Hawaii o Bahrain

5.4.3 Future locations. The Contractor shall have the ability to support DISA or DISA approved locations worldwide where DISA may acquire an operational responsibility.

5.5 Taxes. When applicable and upon the request of the Contractor, DISA will provide the Contractor with documentation to obtain exemptions from local taxes, value-added taxes, excise taxes, and/or other taxes or tariffs incurred in the performance of this contract. If the Contractor is required to pay local taxes, value-added taxes, excise taxes or tariffs in performance of this contract, the Contractor may submit a request for reimbursement to the Government with documentation of such payment. A call order will be generated using an assigned SLIN and will be billed on a cost reimbursable basis.

5.6 Hardware. No hardware currently installed in DISA shall be used to satisfy the initial provisioning requirements of this solicitation. All hardware to support the capacity service brought into DISA locations for the first time must be new hardware. If the call order for capacity service is later cancelled, the hardware to support the service may be reutilized as long as the technology meets the criteria of the most current tier structure, is not a product the OEM has withdrawn from marketing/sale, and/or has not been otherwise designated as end-of-life (EOL) by the OEM. DISA has the final determination on re-use of hardware.

5.7 Storage. The Contractor will ensure all infrastructure components provided are compatible with and operate seamlessly with DISA's processor, communication and storage infrastructure. The Government currently requires the capability to Boot from SAN and mirrored internal storage. The Contractor’s solution must support both capabilities. All tier pricing should be based on a “Boot from SAN” configuration, and the Government will order internal storage separately when it is required. The internal storage SLINs are comprised of an individual storage device. The Level One storage device is the smallest available mainstream, high volume, commercially available drive for the given chipset. The Level Two storage device is the largest mainstream, high volume, commercially available drive for the given chipset. The Level One storage device shall increase in size when the current size is no longer commercially available from the hardware vendor. The Level Two storage device shall increase in size 3 months after release of a new, larger drive. The two levels of storage devices must be of a similar type and form factor.

5.7.1 The Contractor is required to provide all ancillary hardware and/or software required to ensure the internal storage devices are fully functional. All costs for this ancillary hardware and/or software should be included in the internal storage device SLIN pricing.

5.8 Memory. Provide three levels of mainstream, high volume, commercially available Dual Inline Memory Module (DIMM). Level 3 is the highest level DIMM commercially available. Level 2 is the next highest level DIMM commercially available. Level 1 is the third highest level DIMM commercially available. Each memory SLIN will be comprised of one pair of DIMMs. The government views the following as the current individual DIMM sizes for each chipset, the SLINs will however be comprised of two of these individual DIMMs:

Level SPARC Compatible One 16GB Two 32GB Three 64GB

5.8.1 The Contractor is required to provide all ancillary hardware and/or software required to ensure the DIMMs are fully functional. All costs for this ancillary hardware and/or software should be included in the DIMM SLIN pricing. The Contractor must update equipment as ancillary hardware and/or software technology advances at no additional cost to the Government. The Government will make the final determination on all memory configurations.

5.9 Processor Type. As processor technologies advance, the provided processors shall remain within the new generation at the same relative position or better as the previous generation at time of contract award. The proposed processor must be SPARC Compatible and meet the requirements identified in Appendix One Tier Definitions. fall within the group of the E5/E7 processor family positions as illustrated below.

Tier 1 Tier 2 Tier 3 Tier 4 Tier 5 E5-2600 v3/v4 E5-4600 v3/v4 E5-2600 v3/v4 E5-4600 v3/v4 E5 4600 v3/v4

5.10 Technology Advances. When technology advances, the Government will make the final determination on when or if the SLIN configurations will be updated. The monthly rates proposed (in the monthly rates tab of the chipset pricing models) WILL BE the rates used for the life of the contract regardless of technological advances and the replacement of equipment with newer versions. The Contractor must update equipment as technology advances at no additional cost to the Government.

6.0 Performance Requirements.

6.1 Task 1 - Operating Chipset Architecture/Operating Systems.

6.1.1 Subtask 1.1 - Technical Requirements and Architecture.

The hardware/chipset and the operating systems software required to deliver processor capability for DISA is SPARC Compatible (Solaris). are listed below. Statements containing direct chipset references will only apply to their respective contracts.

6.1.1.2 X-86 (Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Oracle Enterprise

Linux, Solaris for X-86)

6.1.1.3 SPARC Compatible (Solaris)

6.1.1.. 4 1 Provisioning Management Infrastructure. The Contractor will provide a management infrastructure solution that includes provisioning capabilities, hardware diagnostics, hardware monitoring, event logging, image repositories or additional back office processes required to reside in a DISA environment to support the Contractor’s technical solution. The Contractor provided infrastructure will be managed and maintained by the Contractor, and will be subject to Risk Management Framework (RMF) accreditation processes as well as relevant DISA STIG and security policies. RMF accreditation must be accomplished before the first order can be placed under this contract.

6.1.2 Subtask 1.2 – OS Requirements. For each Operating System listed under each chipset, tThe Contractor will provide the most current version of that operating system. In addition, the Contractor’s solution will support the two previous versions. The Government defines the most current version as N and the two proceeding versions as minus two (-2). Therefore N-2 is used to describe an OS current version and two major releases back (supportable by the OEM). An example being for the RHEL (Red Hat) 7, RHEL 6, and RHEL 5. Interim “dot” releases (i.e. RHEL 6.1) do not count as a major version. Any software licenses required for the operating systems will include 24x7x365 support.

6.1.3 Subtask 1.3 – Original Equipment Manufacturer (OEM) Technical Support. The Contractor will provide a methodology/process for the Government to access OEM technical support (including hypervisor) for the operating systems being utilized. Maximum use of OEM) commercial documentation will be used (e.g., operator instructions, maintenance manuals, trainer publications) to support the Contractor’s solution.

6.1.3.1 Provide high availability options for OS (clustering) at the local site for tying hardware together as required.

6.1.4 Subtask 1.4 – Image. Provide an image of the DISA operating environment. The image will not run on the capacity services hardware. The image will be for customers in the IT development stage prior to transitioning their projects to DISA. The image is intended to reduce transition issues for customers. This image should include not only the operating system software, but also any other software tools that the Contractor supplies with the bundled capacity provided on the DISA capacity services hardware. The intent is to allow DISA customers the opportunity to develop applications on an image that will "match" their production image when they move from their test environment to the DISA production environment. The Government will not require any support from the Contractor after initial delivery of the image.

Deliverable/s: Provide image that will be distributed to DISA customers.

6.1.5 Subtask 1.5 – Additional Hardware Components. The Government may require the installation of generic add on devices or peripherals to the Contractor provided hardware. These additional components are special use requirements that do not fit into a standard service offering (for example: Crypto card, fax card, etc.). The Government would provide the components for these special use cases and the vendor's only obligation would be to provide installation and de-installation of these components.

6.1.6 Subtask 1.6 – Virtual Environments. Provide solution for X-86SPARC Compatible hypervisor to support robust, scalable virtualization for X-86SPARC-based operating environment environments (e.g., Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Oracle Enterprise Linux, and Solaris for X-86). Solution must provide:

• Hypervisor Ability to create virtual machines (VMs) and/or virtual operating environments (OEs)

• Shared OS virtualization technologies (containers)

• Server hardware and OS virtualization administrative management (base frameworks)

• Server hardware and OS virtualization embedded management (live migration and basic automation of administrative management functions)

• Support role-based access for management and administration functions

• Support a virtualization ratio of at least 20 VMs/VOEs to single hypervisor or host

6.1.6.1 Virtualization for Unix SPARC Compatible environments will be accomplished using native virtual capabilities for Solaris. For native virtual capabilities, the Contractor will provide comparable native virtualization management tools and infrastructure for management and Government provisioning of virtual operating environments. The Government will manage the virtual hosts, placements, relocating environments through administrative and embedded management toolset provided by the Contractor.

6.1.6.2 The intent of the Government is to operate unlimited virtual environments. The Contractor shall provide virtual OE licensing for Solaris, Hypervisorvirtualization solution (if applicable) and the Infrastructure Switching components required by the vendor's solution (if applicable).

The Government will manage the virtual hosts, placements, relocating environments through administrative and embedded management toolset provided by the Contractor. While a single hypervisor approach is desirable, the Contractor may propose their best technical approach to satisfy the hypervisor requirement for Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Oracle Enterprise Linux and Solaris for X-86.

6.1.6.3 All operating environments whether physical (rack mount or modular server) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for the primary out of band (OOB) / enterprise backup network (EBN) connections, and one port is required for the backup out of band (OOB) / enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. The contractor’s solution should provide reliable, cost effective cabling approach that will condense the amount of network cabling and network ports required. Ports for fiber storage connectivity must be distributed across a minimum of 2 Host Bus Adapter (HBA) ports. Fiber channels should support both 8 and 16 GB capabilities. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. All components must be compatible with the government’s network switching infrastructure. The current DISA network environment is identified in Appendix SEVEN, Network Details; however, this environment is subject to change and may not meet the requirements of the vendors proposed solution for this RFP.

The intent of the Government is to operate unlimited virtual environments. on Tier 1 and 2 of the X-86 chipset. The Contractor shall provide virtual OE licensing for Microsoft operating systems, Red Hat Linux operating systems, SUSE Linux operating systems, Oracle Enterprise Linux, X-86 Solaris, Hypervisor solution (if applicable) and the Infrastructure Switching components required by the vendor's solution (if applicable).

6.1.6.4 All operating environments whether physical (rack mount or blade/modular server) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for the primary out of band (OOB) / enterprise backup network (EBN) connections, and one port is required for the backup out of band (OOB) / enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. The contractors solution should provide reliable, cost effective cabling approach thethat will condense the amount of network cabling and network ports required. Ports for fiber storage connectivity must be distributed across a minimum of 2 Host Bus Adapter (HBA) ports. Fiber channels should support both 8 and 16 GB capabilities. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. All components must be compatible with the government’s network switching infrastructure. The current DISA network environment is identified in Appendix xxxSEVEN, xxxxxxNetwork DiagramsDetail; however, this environment is subject to change and may not meet the requirements of the vendors proposed solution for this RFP.

6.1.7 Subtask 1.7 - Software. For all software provided in the Contractor solution, including operating system software, hypervisor solution, as well as, any other software required for the Contractor solution to operate, the Contractor is responsible to ensure they have documentation that confirms software licenses and annual/current support/maintenance levels. In the event of an audit, the Contractor will be required to defend any audit discrepancy found against all software products that the Contractor has acquired in support of this contract.

6.2 Task 2 - Performance/Availability.

6.2.1 Subtask 2.1 - Processor capacity shall deliver 99.95% availability per orderable system with options to deliver up to 99.999 % availability per orderable system. The definitions and performance measurement are identified below.

Performance Measure 1: Operating Platform Availability 99.95%

• Explanation: The percentage of time each system is available for productive use.

• Measurement: (Total available hours for number of calendar days in reporting month – Measurement Exceptions – Time server is unavailable, unable to perform core function, or core function is significantly degraded) / (Total available hours for number of calendar days in reporting month – Measurement Exceptions )*100=“Service Level Attained”. Total available hours = 24x number of calendar days in reporting month for each orderable system.

• Measurement Exception: DISA or customer initiated downtime, Vendor Preventative Maintenance (not break fix or hardware/software repair) that is properly coordinated through the Authorized Service Activity (ASA)/Authorized Service Interruption (ASI) process with DISA and the customer, and environmental failures not attributed to the vendor.

• Availability Objective: 24x number of calendar days in reporting month minus Measurement Exception (see definition above).

• Standard: Satisfactory = 99.95%

• Contractor Responsibility: Maintain operating platform, operating system software (with exception of z-series OS), and related operating equipment in operating condition at a level to meet 99.95% availability.

Performance Measure 2: Operating Platform Availability 99.999%

• Explanation: The percentage of time each system is available for productive use.

• Measurement: 2A (summary): (Total available hours for number of calendar days in reporting month – Measurement Exceptions – Time server is unavailable, unable to perform core function, or core function is significantly degraded) / (Total available hours for number of calendar days in reporting month – Measurement Exceptions)*100=“Service Level Attained”. Total available hours = 24xnumber of calendar days in reporting month averaged over all five nine’s orderable systems.

• Measurement 2B (per system): (Total available hours for number of calendar days in reporting month – Measurement Exceptions – Time server is unavailable, unable to perform core function, or core function is significantly degraded) / (Total available hours for number of calendar days in reporting month – Measurement Exceptions)*100=“Service Level Attained”. Total available hours = 24x number of calendar days in reporting month for each five nine’s orderable system.

• Measurement Exception: DISA or customer initiated downtime, Vendor Preventative maintenance (not break fix or hardware/software repair) that is properly coordinated through the Authorized Service Activity (ASA)/Authorized Service Interruption (ASI) process with DISA and the customer, and environmental failures not attributed to the vendor.

• Availability Objective: 24x number of calendar days in reporting month minus Measurement Exceptions (see definition above).

• Standard: Satisfactory = 99.999%

• Contractor Responsibility: Maintain operating platform, operating system software (with exception of z-series OS), and related operating equipment in operating condition at a level to meet 99.999% availability.

6.2.2 Subtask 2.2 - Provide 24x7x365 problem escalation/resolution support for hardware, operating system software, hypervisor solution, as well as, any other software required for the Contractor solution to operate, and service management infrastructure.

At a minimum, the Contractor shall provide a help desk process, and provide POCs, phone numbers, and escalation chart. The Contractor shall support management level escalation procedures to address any issues that may arise and that may impact operation of the provided services.

6.2.3 Subtask 2.3 - Provide ability to validate and view HW features and components installed under the Contract.

6.2.4 Subtask 2.4 -

Provide central management capability and reporting to include hardware utilization, and error diagnostics of installed hardware components. Coordinate with DISA to provide regularly scheduled reporting as well as ad hoc reports on available data.

Deliverable/s: Central management capability and reporting to include hardware utilization and error diagnostics of installed hardware components. Coordinate with DISA to provide regularly scheduled reporting as well as ad hoc reports on available data.

6.2.5 Subtask 2.5 - Maintenance. The Contractor shall perform all Preventative Maintenance actions as required by the OEM of the installed equipment, including Predictive and Remedial Maintenance, on all equipment delivered as a part of this contract. The Contractor must schedule and perform maintenance with no disruption to production operating environment. Day to day operations management of the hardware does not require Contractor intervention. Software components are capable of remote management and compatible with current DISA dedicated management network. All maintenance requirements are included in the “utility” pricing.

6.2.5.1 Maintenance Repair and Response Time. Provide processing capacity that delivers 99.95% availability per orderable system with options to deliver up to 99.999 % availability per orderable system. Response and repair times for CONUS will be 2 hour response/4 hour repair and OCONUS will be 4 hours response/8 hour repair, unless otherwise agreed to by DISA. The time for responses will begin when the Contractor is notified and will end when the Contractor makes contact with DISA. The time for repairs will be measured beginning when the Contractor is notified and will end when the repair is completed and the equipment is available for use in its original state prior to the outage. Contractor response times do not change the availability requirements, but represent requirements to repair components which might be causing a degraded state. The Contractor shall address solution failures of redundant components which might not impact system availability but do create performance issues or introduce single points of failure in systems.

Provide 24x7x365 problem escalation/resolution support for hardware, operating system software, and capacity management. The Contractor shall provide a multi-level solution for response time after being notified by the Government to commence remedial maintenance for hardware, operating system software, hypervisor solution, as well as, any other software required for the Contractor solution to operate. Each orderable system will be identified to a level of response based on Government need. All maintenance requirements are included in the “utility” pricing.

6.2.5.2 Predictive Maintenance. The Contractor shall monitor equipment/component performance using diagnostics defined in paragraph 6.2.1 for the purpose of identifying whether equipment is operating in accordance with established specifications. This includes hardware, operating system software, hypervisor solution, firmware and software patches, as well as, any other software required for the Contractor solution to operate. Upon determining equipment/component is about to fail or is operating outside OEM specifications, the Contractor shall initiate action to effect repair even though no call for remedial maintenance has been initiated by the C2 Cell (designated DISA Ecosystem work unit) or shift supervisor.

6.2.5.2.1 The Contractor shall call the C2 Cell to inform them they are coming in for predictive maintenance and request a Form 7 be generated and coordinated with the physical site. Upon arrival at the physical site, the Contractor’s technician shall report to the C2 Cell in order to comply with reporting requirements – see paragraph 13.8, ADPE Maintenance Records/DISA Form 7.

6.2.5.3 Remedial Maintenance. Calls will be initiated by the C2 Cell to the Contractor’s toll free help desk service.

The Contractor shall respond and repair, or when necessary, obtain required OEM support, in accordance with this specification. The Contractor shall complete remedial maintenance and maintain the processor capacity availability per orderable system IAW paragraph 6.2.5.1. Upon arrival on site, the Contractor’s technician shall report to the C2 Cell in order to comply with reporting requirements. This includes hardware, operating system software, hypervisor solution, as well as, any other software required for the Contractor solution to operate.

6.2.5.4 Preventative Maintenance. Preventative Maintenance shall be scheduled with the C2 Cell, local site support, and the Contractor. If deemed necessary by the C2 Cell, the preventative maintenance action could require coordination with the customer base of the affected system. In this scenario, the C2 Cell will take required actions to schedule an Authorized Service Activity/Authorized Service Interruption and coordinate the date and time with the affected customers and vendor. This includes hardware, operating system software, hypervisor solution, as well as, any other software required for the Contractor solution to operate. The Contractor shall submit in writing its preventive maintenance schedule for equipment to the Contracting Officer (KO) within 90 days after contract award.

Submission of the schedule shall be in accordance with the Contractor’s format. The preventive maintenance schedule may be modified at no cost by mutual agreement of both parties. The Contractor’s proposed schedule shall not be less than that recommended by the OEM.

6.2.5.4.1 The Contractor shall commence preventative maintenance IAW the approved preventative maintenance schedule within 90 days after award for all maintained equipment. Preventative maintenance shall be scheduled outside the prime system operating hours.

Deliverable/s: Preventative Maintenance schedule within 90 days of contract award.

6.2.5.4.2 If during the course of preventative maintenance, an equipment malfunction is identified, the Contractor shall report the C2 Cell. The malfunction shall be corrected as a Remedial Maintenance Service (see paragraph

6.2.5.3) and comply with and maintain the processor capacity availability per orderable system IAW paragraph

6.2.5.1 processor capacity availability.

6.2.5.5 Remote Diagnostics. Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, hypervisor solution, as well as, any other software required for the Contractor solution to operate. The Contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 30 calendar days after contract performance start.

Deliverable/s: Written confirmation that reports and remote diagnostics support for applicable equipment exist within 30 calendar day of contract award.

6.2.5.5.1 Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.

6.2.6 Subtask 2.6 – Delivery, Installation and Deinstallation. The Contractor must have the ability to provide processor hardware necessary to support contract requirements within 30 days of contract award with or without Contractor provided management infrastructure. The Contractor will acquire, install, deinstall, transport, provide the necessary hardware (including cabinets/racks), hardware maintenance, operating systems software, hypervisor solution, as well as any other software required for the Contractor’s solution to operate, and services to support the processor infrastructure associated with the contract. The Contractor may be required to install hardware in DISA and/or Mission Partner owned racks. DISA will ensure those racks meet the documented rack requirements set forth in Appendix Four. DISA will determine the need for additional processor equipment.

6.2.6.1 Subtask 2.6.1 Delivery of equipment must occur within 30 calendar days of the acceptance of the call order by the Contractor.

6.2.6.2 Subtask 2.6.2 Deinstallation of equipment must occur within 30 calendar days of the acceptance of the return call order by the Contractor.

6.2.6.3 Subtask 2.6.3– Equipment Report. Once an order has been placed, and before delivery, the Contractor will send a report containing equipment information to include serial numbers, worldwide names, MAC addresses, etc. to the Installation mail group (disa.meade.se.list.lob-data-center-sel42-all@mail.mil). This enables the Government to prepare for equipment receipt. The Contractor shall provide the report 7-10 working days prior to equipment delivery.

Deliverable/s: Provide report of equipment information 7-10 working days prior to equipment delivery.

6.2.6.4 Subtask 2.6.4 – Normal equipment delivery/installations/uninstalls. Unless otherwise mutually agreed to, normal equipment installations should be accomplished during normal business hours, 0600-1800 local time, Monday through Friday.

6.2.6.5 Subtask 2.6.5 – Under certain conditions, the Contractor may be required to perform delivery/installation/upgrades/uninstalls outside of normal business hours during evenings and weekends. Although the Government will try to minimize this requirement, the Contractor must plan to work after hours, weekends, and or holidays for delivery/installation/upgrade/uninstalls of new or updated orders. All DISA required after hours support will be reimbursed through an “After Hours Support” SLIN.

6.2.6.5.1 Under certain conditions, the Contractor may be required to be available on “stand by” after hours, weekends, and/or holidays. All “stand by” hours will be included in the technical assistance and consulting support pricing. “Stand by” means having a field engineer available on-site as requested by the Government.

6.3 Task 3 - Capacity.

6.3.1 Subtask 3.1 - Provide processing capacity that is scalable to adjust to increases and decreases in required workload. This includes but is not limited to, CPU, memory utilization, network interfaces (i.e. network interface cards (NIC), etc.),). Provide processing capacity that does not adversely impact existing production workload.

The Contractor shall provide a process for increasing/decreasing capacity for CPU, memory and network interfaces, (i.e. network interface cards (NIC), etc.) within a tier. The Contractor shall provide a process to collaborate with the Government to modify hardware provided within tier(s) as technology advances, chipset performance improves, or other new hardware-based technologies are introduced, without impact to the awarded SLIN price.

6.3.2 Subtask 3.2 - Provide provisioning servers to support the infrastructure at no cost. These servers must be provided by the Contractor in order to image hardware with the current agreed upon images (reference PWS 6.1.4 Subtask 1.4). Provisioning cannot be accomplished via the Wide Area Network (WAN). Solution should include automation capabilities to provide efficiencies in provisioning and automation to streamline recurring vendor and Government tasks. Automation capabilities may be utilized by both the Contractor and the Government in sustainment of provisioned infrastructure.

6.3.3 Subtask 3.3 - Provide processing capacity that is priced on a utility (as used) basis and tier size as defined in Appendix One.

6.3.4 Subtask 3.4 - Provide processing capacity for unclassified and SECRET workloads. This must be separate hardware infrastructure including channels and networks, not sharing components as instructed by DISA Security Technical Implementation Guides (STIGs) http://iase.disa.mil/stigs/Pages/index.aspx . This requirement does not have any impact on the security clearance provisions of the solicitation.

6.3.5 Subtask 3.5 - Provide processing capacity that is moveable. If the Government requires the movement of equipment, the first move of each piece of equipment shall be at no cost to Government. Movement is defined as the transfer of equipment within the same DISA site. There will be a “Relocation Services” SLIN to support relocation of equipment to another DISA site. Once an item of hardware has been moved one time, all subsequent moves are billable via a call order.

6.3.6 Subtask 3.6 - Capacity requirements can be cancelled at any time at no additional cost to the Government with the exception of orders placed using 12 month commitment SLINs. Those orders will remain in service for a minimum 12 month period

6.4 Task 4 - Integration/Interfaces. All equipment provided must work with the existing DISA infrastructure and network. Refer to Appendix One, Appendix Seven and Appendix Eight for additional integration and interface information.

Refer to Appendix One and Appendix SEVEN..

6.4.1 Subtask 4.1 – The Contractor shall provide training/familiarization to DISA System Administrators for provided infrastructure; all training requirements should be included in the utility price. The Contractor’s training plan shall provide all or a combination of the following elements: OEM documentation guides, Computer Based Training (CBT) manuals, training hours and in-person/virtual classroom training at Government and/or Contractor facilities. Technical/training support will be recurring as new hardware is introduced to the processing environment.

Technical/training support will be provided as part of the total managed service. To minimize risk, a Contractor-facilitated plan for training Government personnel on new technologies will be required.

6.4.2 Subtask 4.2 – The Contractor shall provide infrastructure that does not disrupt, conflict, or interfere with DISA's specified Enterprise Systems Management (ESM) architecture. The ESM environment is identified in Appendix Two.

6.4.3 Subtask 4.3 – The Contractor shall ensure all infrastructure components provided are capable of being managed remotely via a dedicated DISA management network.

http://iase.disa.mil/stigs/Pages/index.aspx

6.4.4 Subtask 4.4 – The Contractor shall ensure all infrastructure components provided are capable of being backed-up via a backup network. Infrastructure components provided must be compatible with and operate seamlessly with DISA’s network and storage infrastructure.

6.4.5 Subtask 4.5 – The Contractor shall ensure all infrastructure components provided are coordinated with and agreed to by DISA before introduction into the processing environment.

6.4.6 Subtask 4.6 – The Contractor shall ensure all components are IPv6 capable. Criteria to be considered IPv6 capable are; conformant with the IPv6 standards profile contained in the National Institute of Standards and Technology (NIST) USG IPv6 guidance, NIST SP 800-119, Guidelines for the Secure Deployment of IPv6;

maintaining interoperability in heterogeneous environments and with IPv4; commitment to up-grade as the IPv6 standard evolves; and availability of IPv6 technical support.

6.5 Task 5 – Release Management. The Contractor will work closely with the Government to test and field OS releases and upgrade packages. The Government develops standard documentation on version levels in line with change and configuration management programs. The Contractor will package the initial and upgrade OS releases.

Initial OS releases are only deployed by the Contractor on capacity hardware; however, the initial OS release must be tested, coordinated, and documented with the Government to ensure all images are enterprise compatible. The Contractor manages the OS software repository. This repository will be available to the Government to execute OS upgrades.

6.5.1 Subtask 5.1 – Package OS.

6.5.1.1 Government will lead the operational acceptance testing with Contractor support. The Contractor shall provide release of new OS's and upgrade packaging for all upgrades. Server OS software is owned and licensed by the Contractor, with the Government having right to use through the capacity services contract.

6.5.1.2 Upon receipt of an image from the Contractor, the Government will install, test and validate image for adherence to standards, perform integration testing, provide release documentation or image corrections necessary for seamless integration into the DISA infrastructure. Items to be validated by the Government include introduction of new hardware, patches, or firmware versions to the enterprise; new or upgraded software; and tool integration and functionality such as ESM agents, Blade Logic, HBSS, Veritas, driver compatibility, IAVA compatibility and level, and STIGing to the current DISA level.

6.5.2 Subtask 5.2 - Manage the OS repository, and server. The Contractor shall manage an OS software repository. The repository will be used as a central repository for approved OS version baselines. The Government must be able to pull and install the OS upgrade package for testing on capacity hardware in use under this contract, and will return validated OS packages for support of general provisioning and upgrade processes.

Deliverable/s: OS Repository and availability for Government to execute OS upgrades.

6.6 Task 6 - Installation/Configuration. The Contractor shall install, deinstall, provide power-up configuration within 30 days of acceptance of the call order by the Contractor.

6.7 Task 7 - Security. The Contractor shall comply with all applicable security directives, including the DoD Directive 8500.1, "Information Assurance (IA)"; DoD Instruction 8500.1, "Cybersecurity"; DoD Directive 8570.1, Information Assurance Training, Certification, and Workforce Management; DoD Manual 8570.01-M, Information Assurance Workforce Improvement Program; the Assistant Secretary of Defense Memorandum, Subject:

Disposition of Unclassified DoD Computer Hard Drives, dated June 4, 2001; DISA Security Technical Implementation Guides (STIGs).

6.7.1 Subtask 7.1 – Contractor personnel supporting Information Assurance (IA) functions in Chapters 3, 4 10 and 11 (DoD 8570.01 M Information Assurance Workforce Improvement Program) shall obtain the appropriate DoD-approved IA baseline certification prior to beginning performance. Contractors have up to 6 months to obtain the rest of the qualifications for their position outlined in AP3.T1. Additional training on local or system procedures may be provided by the DoD organization receiving services. Certification reporting will occur bi-annually.

The Contractor shall provide a solution for reporting certifications and certification status of all Contractor personnel performing Information Assurance functions as described in DoD 8570.01-M, Information Assurance Workforce Improvement Program. The Contractor shall provide a solution for ensuring certifications are in compliance with the manual and are identified, documented, and tracked.

Deliverable/s: Bi-annual IA certification reporting. (Bi-annual based on rate of employee turnover in IT field and new technologies emerging)

6.7.2 Subtask 7.2 – All provided hardware and software solutions shall be in compliance with DISA Security Technical Implementation Guides (STIGs). Management solution and infrastructure provided must be compatible with government provided token authentication. (i.e. CAC-enabled)

6.8 Task 8 – Facilities - Racks. The Contractor must follow the stated standard power and rack details as identified in Appendix Four.

6.8.1 Subtask 8.1 - Provide solution that complies with standard rack and power specifications as detailed in Appendix Four.

6.8.1.1 The Contractor shall allow the Government the flexibility to modify rack configurations as necessary to install cooling scheme, this allows for cooling infrastructure modeled per site dynamics by the Government.

6.8.1.2 The Contractor shall include ancillary equipment such as MPDUs, grommets, blanking panels.

6.8.1.3 Each rack shall be supplied with two (2) each three phase “modular power distribution units” (MPDU’s) that mount vertically into the rear access/cabling spaces of the rack and provide a SNMP interface or MODBUS external port capability.

6.8.1.4 Grounding capability must be provided.

6.8.1.5 Each server/enclosure/cabinet must include some form of Cable Management that allows for the server/enclosure/cabinet to slide on the rails without binding or causing interference to airflow.

6.8.1.6 The Contractor will include any manufacturer/vendor equipment required to meet their own mounting and/or warranty standards.

6.8.2 Subtask 8.2 - Provide solution for high density cooling configurations. Additional “high density” cooling technologies may be proposed. The Contractor should consider all technologies, and include those which are deemed most cost effective and efficient. Rack height dimensions will be permitted to exceed maximum height specified if the high density rack cooling solution is attached to the rack and fits within the applicable data center dimensions.

6.8.2.1 The Contractor must allow the Government the flexibility to modify rack configurations as necessary to install cooling scheme, this allows for cooling infrastructure required per site dynamics by the Government.

6.8.2.2 The Contractor must include ancillary equipment such as MPDUs, grommets, blanking panels.

6.8.2.3 Each rack shall be supplied with two (2) each three phase “modular power distribution units” (MPDU’s) that mount vertically into the rear access/cabling spaces of the rack and provide a SNMP interface or MODBUS external port capability.

6.8.2.4 Grounding capability must be provided.

6.9 Task 9 - DISA “Green” Initiatives. IAW U.S. Department of Defense's (DoD) mission to reduce energy costs, decrease reliance on foreign oil, ensure energy security, and achieve sustainability goals, the Contractor will support DISA "green" initiatives for Contractor-provided hardware. To facilitate a partnership between the Contractor and DISA Infrastructure planning, the Contractor shall submit plans, reports, and/or metrics delineating how their hardware supports green initiatives.

6.10 Task 10 - Technology Refresh Program.

Technology Refresh Program is designed to replace aging and out of date processors hardware in order to minimize obsolescence in advance of loss of service or hardware failure. DISA estimates that if a call order for capacity has been in production for 5 years, the Government may decide to refresh the capacity. The Tech Refresh Program will replace the oldest processor equipment as required, but generally processor hardware will have a 5-year service life.

The Government can decide to refresh hardware based on functions and technology updates, at any point in time during the first five years. Although not typical, the Government does require the flexibility when the need arises.

Likewise, special mission requirements mission partner constraints, as well as technical or cost efficiencies and advantages on keeping hardware for longer than the economic life may be encountered during the life of the contract. Joint discussions with vendor and DISA will be executed to determine feasibility and impacts to mission partner, as well as lifecycle management for both DISA and the vendor. These discussions may occur during regular contract reviews and the Government will make the final decision for potential extension of use beyond stated economic life. Without a viable Tech Refresh Program, DISA will be at risk due to the fact that the processors equipment cannot be serviced beyond its lifecycle. The Contractor shall provide technical refreshes to hardware without additional cost to the Government.

6.11 Task 11 – Service Transition and Exit Strategy.

6.11.1 Subtask 11.1 Service Transition Strategy. Transition coordination is critical to the success of this contract.

The Government will oversee the transition of equipment and services between the incumbent and offerorparties.

Provide a solution for SPARC Compatible operating environment transition. Solution must provide.

• Hardware and Software capability to perform physical-to-physical (P2P) server migrations from existing physical environment to contractor’s proposed physical solution.

• Hardware and Software capability to perform physical-to-virtual (P2V) server migrations from existing physical environment to contractor’s proposed virtual solution.

• Hardware and Software capability to perform the transition of virtual machines from existing virtual environment to contractor’s proposed virtual solution.

6.11.1.1 - Incoming Strategy Plan. The contractor shall create a transition strategy plan for assuming responsibility of the contract upon award. The transition strategy plan must identify and encompass all tasks to be performed by the incoming contractor. The strategy should include a list of any questions or information requested of the Government. It will lay out dates for future status meetings and program reviews.