J-1_HC102817R0014_PWS_Amend_003_trackchanges.pdf

HC102817R0014

ZIPPCS PWS

Attachment J-1

AMEND 00020003

PERFORMANCE WORK STATEMENT (PWS)

as of 15 21 June 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 DODAAC: 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) Z–Series, Itanium and System P Processor Capacity Services

(ZIPPCS).

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 communications effectiveness through improved information 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” 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, install, deinstall, transport, configure, and provide the necessary hardware (which may include but is not limited to cabinets/racks/cabling/cable management/PDUs), hardware maintenance, operating system software, and 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, and any other software required for the Contractor’s 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, and maintain 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.

5.1.1 IBM System Z (IBM z/OS, IBM z/VM, Red Hat Enterprise Linux, SUSE Linux Enterprise Server)

5.1.2 Itanium (HP-UX)

5.1.3 IBM System P (AIX)

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 and 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 o Warner Robins, GA

5.4.2 OCONUS locations:

o Germany o Hawaii o Bahrain

5.4.2.1 At this time , there are no current OCONUS requirements for any of the three chipsets, however, DISA may have future OCONUS requirements as DISA missions change.

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 or vendor management stack 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 server 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 chip-set. The Level Two storage device is the largest mainstream, high volume, commercially available storage device 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 re-lease of a new, larger storage device. The two levels of storage device 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.7.2 Internal storage is not a requirement for the IBM System Z chipset.

5.8 Memory. Provide three levels of mainstream, high volume, commercially available Dual Inline Memory Module (DIMM) for Itanium chipsets. 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.

Provide Five Levels of mainstream, high volume, commercially available Dual Inline Memory Module (DIMM) for Power chipsets. Level 5 is the highest level DIMM commercially available. Level 4 is the next highest level DIMM commercially available. Level 3 is the third highest level DIMM commercially available. Level 2 is the fourth highest level DIMM commercially available. Level 1 is the fifth 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 Itanium Power One 4GB 4GB Two 8GB 8GB Three 16GB 16GB Four 32GB Five 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.8.2 This is not a requirement for the IBM System Z chipset.

5.9 Processor Type. As processor technologies advance, the provided processors shall remain within the new generation at the same position or better as the previous generation at time of contract award.

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:

6.1.1.1 IBM System Z (IBM z/OS, IBM z/VM, Red Hat Enterprise Linux, SUSE Linux Enterprise Server)

6.1.1.1.1 The Government defines the IBM z13s and Rockhopper models as the "N" systems; the Government requires support for "N" and "N+1" systems.

6.1.1.2 Itanium (HP-UX)

6.1.1.3 IBM System p (AIX)

6.1.1.4 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, the 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.

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 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.4.1 Image provisioning is not a requirement for the IBM System Z chipset.

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 of these components.

6.1.6 Subtask 1.6 – Virtual Environments. Virtualization for Unix environments will be accomplished using native virtual capabilities for HP-UX, and AIX. For native virtual capabilities, the Contractor will provide comparable native virtualization management tools and infrastructure for management and Government provisioning of virtual operating environments.

6.1.6.1 All operating environments whether physical (rack mount or blade) 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 out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. 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.

6.1.7 Subtask 1.7 - Software. For all software provided in the Contractor solution, including operating system software, 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.1.7.1 – IBM System Z: The System Z operating system is not required for this contract. The Contractor will not provide any Z-Series operating system software. DISA will provide and maintain all Z-Series operating system software.

6.1.8 Subtask 1.8 – Operating System Console Management Hardware. The Contractor will provide operating system console management hardware. DISA requires:

6.1.8.1 The flexibility to replace an OS console environment at both a site level (all at once) and at a mainframe level.

6.1.8.2 Capability to connect gateways with multiple mainframes using OSA channels.

NOTE: FICON gateways are still required, but not for consoles. The old fiber connected consoles were ESCON (z10 and previous models), which went to a channel converter and then converted to coax.

6.1.8.3 Capability to support multiple (minimum of 10) OS sessions per console.

6.1.8.4 Capability to support IP connections for Remote Console support.

6.1.8.5 Capability to support IP connections for message consolidation management solutions (currently BMC Mainview Console Automation).

6.1.8.6 Required fiber optic cabling and connectors as necessary for connectivity to peripherals such as FICON switches, Storage devices, Communications devices, Integrated Coupler, , Infiniband, etc. Contractor will provide solution/s for fiber optic cabling and connectors.

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%.

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%.

6.2.2 Subtask 2.2 - Provide 24x7x365 problem escalation/resolution support for hardware, operating system software, 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.

6.2.4 Subtask 2.4 - Provide central management capability and reporting to include hardware utilization, and error diagnostics of installed hardware components.

Deliverable/s: Central management capability and reporting to include hardware utilization and error diagnostics of installed hardware components.

6.2.5 Subtask 2.5 - Maintenance. The Contractor shall perform all Preventative Maintenance actions as required by the OEM, 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 Critical Support for Itanium (HP-UX) Chipset. A maintenance requirement for the Itanium chipset dictates the need for a subset of servers to have Critical Services Support to include a single core package for the contract life and associated extensions for each subsequent server ordered. This requirement should include all of the services associated with the HP’s Critical Services Support program.

6.2.5.2 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 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 will provide a multi-level solution for response time after being notified by the

Government, to commence remedial maintenance for hardware, operating system software 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.3 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, as well as, any other software required for the Contractor’s 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 or shift supervisor.

6.2.5.3.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.4 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.2. 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, as well as, any other software required for the Contractor’s solution to operate.

6.2.5.5 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, as well as, any other software required for the Contractor’s 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.5.1 The Contractor shall commence preventative maintenance IAW the approved preventative maintenance schedule within 90 days after award for all maintenance 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.5.2 If during the course of preventative maintenance, an equipment malfunction is identified, the Contractor shall report the malfunction to the C2 Cell. The malfunction shall be corrected as a Remedial Maintenance Service (see paragraph 6.2.5.4) and comply with and maintain the processor capacity availability per orderable system IAW paragraph 6.2.5.2 processor capacity availability.

6.2.5.6 Remote Diagnostics. Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, 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.6.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.5.6.2 The dial-in feature for remote access to equipment can be used, but ONLY with C2 Cell authorization.

The feature must be capable of disabling and set up to provide the C2 Cell the ability to enable the feature upon request from the Contractor.

6.2.6 Subtask 2.6 – Delivery, Installation and Deinstallation. The Contractor shall provide processor hardware necessary to support contract requirements. The Contractor will acquire, install, deinstall, transport, provide the necessary hardware (including cabinets/racks), hardware maintenance, operating systems software, 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 will in some cases be required to install hardware in DISA and/or Mission Partner owned racks. DISA will ensure those rack 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 installation requirements should be included in the “utility” pricing.

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, MIPS, memory utilization, network interfaces (i.e. network interface cards (NIC), etc.), sysplex hardware, channels and channel infrastructure). Provide processing capacity that does not adversely impact existing production workload.

The Contractor shall provide a process for increasing/decreasing capacity for CPU, MIPS memory, network interfaces, (i.e. network interface cards (NIC), etc.), sysplex hardware, channels and channel infrastructure) 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).

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.2.1 Provisioning servers is not a requirement for the IBM System Z chipset

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 – For IBM System Z, provide IBM Mainframe Capacity Backup (CBU) feature for the temporary activation of Central Processors for Disaster Recovery. Annually, DISA routinely conducts 100 days of testing for disaster recovery. Testing days will be included in the processor utility service. Invocation fees will be identified and priced separately.

6.3.5 Subtask 3.5 - 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.6 Subtask 3.6 - Provide processing capacity that is moveable. If this 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 and item of hardware has been moved one time, any subsequent moves are billable via a call order.

6.3.7 Subtask 3.7 - 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 Four.

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 dedicated 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 with exception of Mainframe OS software which is owned, licensed, and supported by the Government. 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.5.2.1 Image Repository not required for System P or Z Series.

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 Contractors must follow the stated standard power and rack details as identified in Appendix Four.

This is not a requirement for the IBM System Z chipset.

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.23 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 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 parties.

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. It will include details about the call order system being provided and schedule for training of Government staff.

Deliverable/s: Meeting with the Government within 30 days of award to plan the transition strategy. Written plan for transitioning current operating environments to Contractor provided utility solution(s) within 60 days of award with mutually agreed to milestones.

6.11.1.2 - Execution. The contractor will work with PMO to execute the transition tasks.

6.11.2 Subtask 11.2 Exit Strategy. The contractor shall create a detailed exit strategy for the end of the contract.

The exit strategy shall assist the Government in the transition of services from this contract to any follow-on contractor. The contractor must agree to coordinate service transition with any follow-on contractor to prevent service disruption during the transition. Processor capacity requirements can be ordered in the base period and all option years. The contractor shall be responsible for the removal of all contractor owned equipment related to this contract at the end of the contract (which includes any option periods if exercised) at no cost to the Government.

The contractor shall provide an exit strategy based on these criteria. However, an alternative plan may be provided by the Government, and will be evaluated by the contractor for mutual agreement.

6.12 Task 12 - Removal of Equipment. The Contractor shall conduct any necessary deinstallation and removal of hardware items on this contract upon request by the Government both during and at the end of the contract, at no additional cost to the Government. Removal of all vendor equipment will be coordinated with the Government.

Components and/or writeable media being removed from the site (tapes, hard drives, mass storage devices, etc.) will be sanitized or may be retained by the government for destruction in accordance with DoD, DISA and DISA Security guidance at no cost to the government. The Contractor must be aware that the sanitation process is to prevent any compromise of classified and/or controlled unclassified data and may render the system components and/or writeable media unserviceable and/or completely destroyed. The Government will make the determination as to whether drives can be sanitized or destroyed.

6.13 Task 13 - Quality Program. The Contractor shall implement a quality program that uses Information Technology Infrastructure Library (ITIL) fundamentals.

The Contractor shall implement established processes for Change Management, Configuration Management, Incident Management, Asset Management, and Release Management and seek to remain compatible with how these processes are used within DISA.

6.13.1 Industry Standard.