J-2 Processor Requirements Document 17 Aug 11 AM005.doc
DOC document 1 MB Posted
- Attached to
- Processor Capacity Services
- Solicitation number
- HC1028-11-R-0104
- Issued by
-
Defense Information Systems Agency
About this file
Atch J-2 Processor Requirements Document rev 17 Aug 2011
View the file
Other files
Show 40 more
50 files listed here. See the rest on GovTribe.
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Acquisition Sensitive
Attachment J-2
HC1028-11-R-0104
Acquisition Sensitive
Attachment J-2
HC1028-11-R-0104
Amendment 0005
REQUIREMENTS DOCUMENT
PROCESSOR ENVIRONMENT
1.0 TECHNICAL REQUIREMENTS.
1.1 Operating Chipset Architecture/Operating environments: The scope of this project includes the hardware/Chipset and the operating systems software, required to deliver processor capability for DISA:
1.1.1 IBM System z (IBM z/OS, IBM z/VM, , Red Hat Enterprise Linux, SUSE Linux Enterprise Server)
1.1.2 X-86 (Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Solaris, VMware)
1.1.3 Itanium (HP-UX, HP VSE)
1.1.4 SPARC (Solaris, Solaris 10 zones and Ldoms)
1.1.5 IBM System p (AIX, AIX LPARs)
1.1.6 This also includes any other operating environment or chipsets that DISA may require in the future.
1.1.7 This initiative will include both the unclassified and classified environments.
1.1.8 Current Environments
1.1.8.1 DISA CSD currently provides processor services at fifteen (15) computing facilities and locations in the CONUS, located at:
· Chambersburg, PA,
· Columbus, OH,
· Dayton, OH,
· Denver, CO
· Fort Meade, MD
· Huntsville, AL,
· Jacksonville, FL
· Pensacola, FL
· Mechanicsburg, PA,
· Montgomery, AL,
· Ogden, UT,
· Oklahoma City, OK,
· San Antonio, TX,
· St Louis, MO,
· Warner Robins, GA
1.1.7.2 Three (3) OCONUS locations are:
· Patch Barracks, Vaihingen, Germany
· Pearl Harbor, Hawaii
· Manama, Bahrain
1.1.7.3 Future locations. Offeror shall have the ability to support DISA or DISA approved locations worldwide where DISA CSD may acquire an operational responsibility.
1.1.7.4 Classification. All locations may require a NIPR, SIPR and the potential for a Sensitive Compartmented Information Facility (SCIF) environment.
1.2 Technical Requirements and Architecture:
1.2.1 OS Requirements: For Operating systems listed under each chipset, the offeror will provide the most current operating system; additionally provide and support for two versions back. 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 RHEL (Red Hat) 6, RHEL 5, and RHEL 4.
1.2.1.1 The offeror will provide a methodology/process for the Government to access OEM technical support for the operating systems being utilized.
1.2.1.2 Provide high availability options for OS (clustering) at the local site and/or remote site for tying hardware together.
1.2.1.3 Provide an “image” of the CSD operating environment. The “image” will not run on the capacity services hardware. The “image” will be purchased for customers in the IT development stage prior to transitioning their projects to CSD. Purchase of the “image” for customers is intended to reduce transition issues. This image should include all operating system software, monitoring software, etc that would normally be provisioned via service. This service should be priced as a one-time purchase.
1.2.2 Additional Hardware Components: The Government will require utility service methods for adding generic add on devices or peripherals to the hardware (for example: Crypto card, fax card, MUX card, more RAM, etc.).
1.2.3 Virtual Environments: Provide solution that recognizes VMware/VSphere as the standard infrastructure for the x86 virtual environment. The Government support staff will manage the virtualhosts, placements, relocating environments (vmotion), and the VIC. The x86 virtual software will be included in the processor utility service. Offeror will provide the underlying infrastructure, tools, software, licensing, and licensing agreements to support the x86 virtual infrastructure as well as native virtual capabilities for HP-UX, Solaris, and AIX.
1.2.3.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 2 separate physical Host Bus Adapter (HBA) cards. 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.
1.2.4. Software: For all software provided in the offeror solution, including operating system software , VMWare, as well as, any other software required for the offeror solution to operate, offeror is responsible to ensure they have documentation that confirms software entitlements and annual/current support/maintenance levels. In the event of an audit, the offeror will be required to defend any audit discrepancy found against all software products that the offeror has acquired in support of this contract.
1.2.5 IBM System z: The System z operating system is not required for this contract. The offeror will not provide any z-Series operating system software. DISA will provide and maintain all z-Series operating system software.
1.2.5.1 The offeror will provide operating system (OS) console management hardware. DISA requires:
1.2.5.1.1 The flexibility to replace an OS console environment at both a site level (all at once) and at a mainframe level.
1.2.5.1.2 Capability to connect gateways with multiple mainframes utilizing FICON or OSA channels.
1.2.5.1.3 Capability to support multiple (minimum of 10) OS sessions per console.
1.2.5.1.4 Capability to support IP connections for Remote Console support.
1.2.5.1.5 Capability to support IP connections for message consolidation management solutions (currently IO Concepts).
1.3 Maintenance. Provide all Preventative maintenance actions as required by the Original Equipment Manufacturer (OEM), Predictive and Remedial Maintenance, on all equipment delivered as a part of this contract.
1.3.1 Maintenance Response and Repair Time.
Provide processing capacity that delivers or exceeds 99.95% availability per orderable system with options to deliver or exceed 99.999 % availability per orderable system.
Provide 24x7/365 problem escalation/resolution support for hardware, operating system software, and capacity management. The offeror will provide a multi-level solution for response after being notified by the Government, to commence remedial maintenance for hardware, operating system software , VMWare, 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.
1.3.2 Maintenance types.
1.3.2.1 Predictive Maintenance. Contractor shall monitor equipment/component performance using diagnostics defined in paragraph 1.3.2.4 for the purpose of identifying whether equipment is operating in accordance with established specifications. This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall, upon determining equipment/component is about to fail or is operating outside OEM specifications, initiate action to effect repair even though no call for remedial maintenance has been initiated by the site help desk or shift supervisor.
Contractor shall call the help desk or shift supervisor to inform them they are coming in for predictive maintenance and upon arrival on site. Contractor’s technician shall report to the site help desk or shift supervisor in order to comply with reporting requirements.
1.3.2.2 Remedial Maintenance. Calls will be initiated by the site help desk or shift supervisor to the contractor’s toll free help desk service. 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 1.3.1. Upon arrival on site, contractor’s technician shall report to the site help desk or shift supervisor in order to comply with reporting requirements. This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate.
1.3.2.3 Preventative Maintenance. Preventative maintenance shall be scheduled with the managing site POC, local site support, and the contractor. If deemed necessary by the DISA managing site POC, the preventative maintenance action could require coordination with the customer base of the affected system. In this scenario, the managing site POC 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, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall submit in writing its preventive maintenance schedule for equipment to the Contracting Officer (KO) within 30 days after contract award. Submission of the schedule shall be in accordance with contractor 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 and shall include, as a minimum, the following information:
· Nomenclature of hardware item.
· Model.
· Serial Number.
· Remote diagnostics and reporting capabilities
· Frequency and duration of preventive maintenance, and type of service to be performed.
The contractor shall commence preventative maintenance IAW the approved preventative maintenance schedule within 30 days after award for all maintenance equipment. Preventative maintenance shall be scheduled outside the prime system operating hours.
If during the course of preventative maintenance, an equipment malfunction is identified, the Contractor shall report the malfunction to the site POC. The malfunction shall be corrected as a Remedial Maintenance Service (see paragraph 1.3.2.2) and comply with processor capacity availability per orderable system (see paragraph 1.3.1).
1.3.2.4 Remote Diagnostics. Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start.
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.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
1.4 Industry Standards. Implementation of components of the Information Technology Infrastructure Library (ITIL) will improve overall management of DISA’s processor infrastructure. Companies and Government agencies that have followed the methodologies of these models have improved their service and reliability of their processor infrastructure reducing their long-term costs. The following ITIL principles should be included in the contract:
· Change Management,
· Configuration Management,
· Asset Management,
· Release Management.
1.4.1 Change Management. An established process for handling change to the processor infrastructure on a continual basis shall be developed. Over an eight year period (5 year base with 3 option years) technologies will change, software will be revised, and hardware will be phased out by the manufacture. By having a process in place to handle these inevitable events, time and money can be saved. It will also be necessary to incorporate DISA customer requests for new or revised functionality. Changes in focus and/or mission of some or all the DISA business processes will play a role in the type of changes that may need to be incorporated into Tech Refresh Program over an eight year span. This will specifically address end of life and unsupportable issues which may occur during the life of this contract.
1.4.2 Configuration Management. An established process for managing the infrastructure’s processor configuration shall be developed by the offeror. One method to reduce the cost of Configuration Management is to reduce the types of hardware in the environment. By maintaining the configurations over the eight year period, DISA will be able to improve break-fix and trouble tickets because less time will be spent on issue resolution. Further, this reduces the over-all complexity of the infrastructure from a management standpoint. The contractor will provide monthly configuration/asset summary reports for configuration/asset validation by the Government.
1.4.3 Asset Management. An established process for handling asset recovery and redeployment shall be developed by the offeor.
1.4.4 Release Management. An established process for performing package releases to the infrastructure shall be developed. Release Management works to ensure you have strong Configuration Management and Change Management, and works alongside Asset Management to ensure that any assets are introduced into the infrastructure correctly and with the minimum of difficulty.
2.0 Performance/Availability. Processor capacity shall deliver or exceed 99.95% system availability per orderable system with options to deliver or exceed 99.999 % availability per orderable system.
2.1 Provide 24x7/365 problem escalation/resolution support for hardware, operating system software, a VMWare, as well as, any other software required for the offeror solution to operate, and service management infrastructure.
2.2 Provide ability to validate and view HW features and components installed.
2.3 Provide central management capability and reporting to include hardware utilization, error diagnostics of installed hardware components, and environmental telemetry information to measure power consumption and HVAC impact to CSD facilities and infrastructure.
3.0 Capacity. Provide processing capacity that is scalable to adjust to increases and decreases in required workload. This includes but is not limited to, CPU utilization, MIPs, memory utilization, network interfaces (i.e. OSA, HBA, and network interface cards (NIC)), sysplex hardware, channels and channel infrastructure). In addition, this includes the following:
3.1 Provide provisioning servers to support the infrastructure. These servers must be provided by the offeror in order to image hardware with the current agreed upon images. Provisioning cannot be accomplished via the wide area network (WAN).
3.2 Provide processing capacity that is priced on a utility (as used) basis and tier size.
3.3 Provide IBM Mainframe Capacity Backup (CBU) feature for the temporary activation of Central Processors for Disaster Recovery. Annually, DISA routinely conducts 100-140 days of testing for disaster recovery. Testing days will be included in the processor utility service. Invocation fees will be identified and priced separately.
3.4 Provide processing capacity for Classified 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/stig/index.html. This requirement does not have any impact on the security clearance provisions of the solicitation.
3.5 Provide processor capacity that does not adversely impact existing production workload.
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 the Government. Movement is defined as the transfer of equipment within the same DISA site or from one DISA site to another DISA site within CONUS. There will be a “Relocation Services” CLIN to support this requirement. Once the free move has been used for specific hardware, subsequent moves are billable via a call order.
3.7 Capacity can be cancelled at any time at no cost to the Government.
4.0 Integration/Interfaces. All equipment provided must work with the existing DISA infrastructure and network.
4.1 The offeror will provide training/familiarization to DISA system administrators for provided infrastructure; all training requirements should be included in the utility price.
4.2 The offeror will provide infrastructure that does not disrupt, conflict, or interfere with DISA's specified enterprise systems management (ESM) architecture. The ESM environment is identified in ATTACHMENT THREE.
4.3 The offeror will ensure all infrastructure components provided are capable of being managed remotely via a dedicated DISA management network.
4.4 The offeror will ensure all infrastructure components provided are capable of being backed-up via a dedicated backup network.
4.5 The offeror will ensure all infrastructure components provided are compatible with and operate seamlessly with DISA’s processor and storage infrastructure.
4.6 The offeror will ensure all infrastructure components provided are coordinated with and concurred by DISA before introduction into the processing environment.
4.7 The offeror will ensure all components are IPv6 capable. This is defined as a system or product capable of receiving, processing and forwarding IPv6 packets and/or interfacing with other systems and protocols in a manner similar to that of IPv4. Criteria to be considered IPv6 capable are: conformant with the IPv6 standards profile contained in the DoD IT Standard Registry (DISR); maintaining interoperability in heterogeneous environments and with IPv4; commitment to upgrade as the IPv6 standard evolves; and availability of IPv6 technical support.
5.0 Release Management. The offeror will work closely with the Government to field and test OS releases and upgrade packages. The Government develops standard documentation on version levels in line with change and configuration management programs. The offeror will package the initial and upgrade OS releases. Initial OS releases are only deployed by the offeror 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 offeror manages the OS software repository. This repository will be available to the Government to execute OS upgrades.
5.1 Government will lead the operational acceptance testing with offeror support. The offeror does 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 offeror, with the Government having right to use through the capacity services contract.
5.2 Upon receipt of a base line image from the offeror, 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 CSD 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, HBSS, Veritas, driver compatibility, IAVA compatibility and level, and STIGing to the current DISA level.
5.3 - Manage the OS repository, mainframe and server. The Contractor manages the OS software repository and will be used as a central repository for approved OS version baselines. The Government will 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.
6.0 Facilities - Racks. Rack and power specifications are listed in ATTACHMENT FIVE. Offerors must follow the stated standard power and rack details. Each chipset offeror may provide multiple rack configurations, a “standard” construct and rack configurations which include cooling solutions to allow the Government to populate the rack at a higher density than specified in ATTACHMENT FIVE while appropriately cooling the installed equipment. Each rack configuration will be priced separately. Additional “high density” cooling technologies may be proposed by the offeror.
6.1 Offeror must 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.2 Offeror must include the following ancillary equipment: MPDUs, grommets, blanking panels.
6.3 Equipment will be connected to Building Automation System (BAS) for control and monitoring.
6.4 Grounding capability must be provided.
6.5The Government reserves the right to choose the basic rack solution or the “spot” cooling rack solution at the time of order based on workload and infrastructure requirements specified at the time of the order.
6.6 The racks will be priced on a capacity service basis per month.
6.7 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 Offeror will also include any manufacturer/vendor equipment required to meet their own mounting and/or warranty standards.
7.0 Installation/Configuration. All installation, uninstallation, and power-up configuration will be completed by the Offeror based upon Government approval. The Government will perform final configuration as required.
8.0 Transition and Exit Strategy. The transition and exit strategy will begin at the end of the base contract. The Governments goal is that there will be a follow on contract in place by the end of the base period. It is the Governments desire that the option years will be exercised for sustainment of all orders. However, the Government can place new orders against the new contract in the extension years should the need arise for the following purposes: the existing contract ends, the equipment is technically refreshed, or the equipment is no longer required by the Government. At the end of the option years of the contract, or cancelling a call order, the offeror shall be responsible for the removal of all their offeror owned equipment related to this contract at no cost to the Government.
9.0 Removal of Equipment: The offeror shall conduct any necessary uninstallation and removal of hardware items on this contract upon request by the Government both during and at the end of the contract, at no cost to the Government.
10.0 Delivery and Installation. The offeror shall provide processor hardware necessary to support contract requirements. The offeror will acquire, install, uninstall, transport, provide the necessary hardware (including cabinets/racks), hardware maintenance, operating systems software, VMWare, as well as any other software required for offeror solution to operate, and services to support the processor infrastructure associated with the contract.
10.1 Processor deliverables should have the capability to utilize an on-demand service approach that will readily adjust to changes in processing requirements, both increases and decreases.
10.2 DISA CSD will determine the need for additional processor equipment. Delivery of equipment must occur within 30 calendar days of the acceptance of the order by the offeror.
10.3 Normal equipment installations should be accomplished during normal business hours, 0600-1800 local time, Monday through Friday. Under certain conditions, the offeror may be required to perform an installation/update after normal business hours during evenings and weekends. Although the Government will try to minimize this requirement, the offeror must plan to work after hours, weekends, and or holidays for delivery and installation of new or updated orders. All installation requirements should be included in the “utility” pricing.
10.4 Once an order has been placed, and before delivery, the offeror will send a report containing equipment information to include serial numbers, worldwide names, MAC addresses, etc to the DISA Installation mail group (csd-installations@csd.disa.mil)). This enables the Government to prepare for equipment receipt. The offeror will provide the report 10 working days prior to equipment delivery.
11.0 Technical Assistance and Consulting Support. Technical support may be provided on as needed basis to provide flexibility to modify services to meet the needs of DISA and its customers. The support will be divided into five levels depending upon the level of support required. See ATTACHMENT FOUR. The labor categories will also be used for performing services that will require a Firm-Fixed Price effort with a detailed agreement with DISA on the scope of work. After contract award, all requirements must be staffed through the offeror and government Program Management Offices. Any contractual requirement obtained via another source (i.e., sales) will not be addressed. Technical Assistance and Consulting Support is a specified requirement needed by DISA and does not include predictive, remedial, or preventative maintenance for hardware, software, racks, or release management.
11.1 Job Family Description: Responsible for providing technical support and/or leadership in the creation and delivery of technology solutions designed to meet the Government’s business needs.
11.2 The offeror will be responsible for funding any training and certification testing as well as any certification maintenance requirements. In addition, the offeror will ensure the appropriate Operating System, Operating Environment, or Virtual Environment and Security certifications are met and maintained, in accordance with Government guidance (IAW DoD 8570.01-M Information Assurance Workforce Improvement Program). Certification must be gained within six months of offeror personnel commencing service.
12.0 Risk of Loss - The offeror shall be liable for loss of or damage to supplies as long as the offeror holds title to the supplies furnished under this service contract. This liability shall not apply when the loss or damage is caused by the negligence of officers, agents, or employees of the Government acting within the scope of their authority.
13.0 Ordering/Payment Process
13.1 Ordering. All services will be placed via a call order process. A call order will be initiated by the Government through authorized call order personnel. No call orders shall be accepted by the offeror in excess of the authorized funding on the delivery order for each line item.
13.1.1 The offeror must provide an ordering process to effectively manage the introduction or termination of technology, as well as changes to current and existing capacity offerings.
13.1.2 The offeror must provide standard operating procedures to support the system including but not limited to the following: management of new or first time orders, returns, back orders, special orders, processing invoices, processing refunds, credits and exchanges, managing both deliveries and lost deliveries, billing processes, complying with quality assurance reviews and effectively balancing/managing inventories with orders.
13.1.3 On a regular basis the Government may have a requirement for new/revised IT products which shall require a fast turn-around time. Consequently, the offeror must be able to expeditiously respond to requests to accomplish any changes and must be able to specify a response time relevant to accomplishing any Government requested change to a product line.
13.1.4 After contract award, all orders/requirements must be staffed through the vendor and government Program Management Offices. Any contractual requirement obtained via another source (i.e., sales) will not be addressed.
13.1.5 The vendor has eight (8) business hours (Eastern Standard Time) to validate a call order for accuracy. Once the vendor validates a call order for accuracy, the hardware should be delivered within 30 days. Call orders received on Friday, requires validation by the following business day.
13.2 Call Order Management System. Offeror will create a web-based, call order management system. This system will be utilized to create and place call orders (including cancellations and amendments), document, and update order status, and track financial data associated with the call order. It must be able to track excess hardware and software for re-utilization.
13.2.1 The offeror call order management system will include the ability to cancel existing equipment/workload and remove capacity services gear from the DISA site within 30 days.
13.2.2 The offeror call order management system will manage excess hardware, and software licenses. Excess hardware and software will be defined as any hardware and/or software that has received a 'cancelation' request via the call order process. This equipment will be marked in the call order management system appropriately to include cancelation date and date removed from DISA location.
13.2.2 Format will include information defined in sample call order template (ATTACHMENT SIX). After contract award, contractor will collaborate with DISA to finalize format and information required.
13.2.4 The call order management system must be able to handle the complete order process to include. but not limited to the following: ordering, order validations, invoicing, billing, returns, financial tracking, and offeror asset management, throughout the life of the contract.
13.2.5 The call order management system must track equipment moves to include the equipment moved, date/s of move/s, which site equipment moved from and which site equipment moved to.
13.2.6 The call order management system will contain not more than two decimal places in the financial data.
13.3 Acceptance. The acceptance of equipment by the Government will start the billing cycle for this service. The offeror will work with DISA to develop an acceptance validation to smoothly transition equipment into the DISA production environment. The official acceptance validation documentation will be provided by the Government after the contract award.
13.4 Deactivation. Billing will stop based on the date of deactivation of the equipment and official cancellation of the original call order, not removal of the equipment from the DISA site.
13.4 Technical Refresh & Acquisitions. Service will be priced in accordance with sections 3.0 and CLINS/SLINS.
13.5 Technical Assistance. Technical assistance will be priced on a firm fixed price hourly basis for each of the five categories of support. The offeror is authorized to invoice only for hours authorized by call order. ATTACHMENT FOUR lists the technical categories. Technical Assistance and Consulting Support is a specified requirement needed by DISA and does not include predictive, remedial, or preventative maintenance for hardware, software, racks, or release management.
13.6 Moving. Movement is defined as the transfer of equipment within the same DISA site or from one DISA site to another DISA site. There will be a “Relocation Services” CLIN to support this requirement.
13.6.1 CONUS. If movement is required within CONUS, the first move of each piece of equipment (both DISA site to site and within DISA sites) will be completed by the offeror at no cost to the Government. Once the free move has been used for specific hardware, subsequent moves are billable via a call order.
13.6.2 OCONUS. If movement is required OCONUS, the first move within a OCONUS DISA site (i.e. OCONUS site to same OCONUS site) will be completed by the offeror at no cost to the Government. Once the free move has been used for specific hardware, subsequent moves are billable via a call order. If movement is required between OCONUS sites, moves are billable via a call order.
13.7 Travel. Travel will be priced on a cost basis, in accordance with Joint Travel Regulations (JTR). Travel may be required on limited basis as requested by DISA. Travel will be permitted with authorization from the Contracting Officer Representative (COR) by issuance of call order authorizing estimated travel expenses for work to be performed. Reimbursement will be IAW JTR only after receipt of expense details. Charges for travel are permissible only in connection with a call order placed for technical support services as called for in the PWS. All other travel costs will be included in the utility chipset cost.
13.8 Invoice Creation and Billing Cycle.
13.8.1 Offeror will provide solutions to create invoices directly from order data and does not require the collection, manipulation, or review of utilization data. Offeror will create the invoice directly from data provided by DISA in its “contract call order,” augmented by the “Acceptance” and “Deactivation” date that begins monthly charges (increases and decreases) for the resources ordered and provisioned. Offeror will employ a monthly billing cycle with 30 days per month. At the end of a month, the order processing system is queried to display a sample invoice based on:
1. Orders that remained in service the entire month with no changes;
2. Orders placed in service during the month using the 15th of the month rule (as defined in para 13.8.1.1); and
3. Orders implemented during the month that reduced or cancelled services using the 15th of the month rule (as defined in para 13.8.1.1).
13.8.1.1 15th of the Month Rule. Acceptance that occurs prior to the 15th of the month will be billed for the entire month in which acceptance has occurred. Acceptance that occurs after the 15th of the month, billing will begin with the following month. For deactivations that occur prior to the 15th of the month, no billing will occur for the entire month in which the deactivation occurs. For deactivation's that occur after the 15th of the month, billing will be for the entire month.
13.8.1.2 Contractor will create a draft invoice and submit it to the designated DISA COR who reviews/corrects, as necessary, the draft invoice. Following this feedback, contractor formally submits the invoice via the DoD Wide Area Workflow System (WAWF). The invoice will be constructed to DISA specification and supporting details will be appended in the form of a spreadsheet file that can be easily manipulated to provide a variety of different sorts and views of the underlying data. Submission of the monthly invoice for the prior month’s activity is routinely completed no later than the fifth of the month.
13.8.1.3 Invoices will contain not more than 2 decimal places.
14.0 Meeting Requirements
Program meetings will be required and held at various geographical locations. The offeror shall include all costs associated with meeting attendance in the proposed prices.
14.1 Contract Kickoff Meeting. The Government and contractor will have a contract kickoff meeting. This will occur shortly after award of the contract. The site will be determined by the Government. The purpose of the meeting is to review the requirements and processes of the contract.
14.2 Semi-Annual Review Meetings. Government and contractor will have contract semi-annual meetings. The meeting site or forum will be determined by the DISA program manager. The meeting will be held to review contract status. The Government is the only party that has the unilateral right to cancel or change a meeting. The contractor shall prepare a report summarizing the meeting within five workdays after completion.
14.3 Recurring Teleconference. At least weekly, there will be a recurring status teleconference meeting on various issues, more frequent if needed. The time will be mutually agreed upon. The Contractor will provide a toll free conference line. The Government is the only party that has the unilateral right to cancel or change a teleconference. Contractor shall prepare the agenda and email report summarizing the discussion within one workday after completion.
14.4 Recurring Installation/Repair Status Teleconference. At least weekly, there will be a recurring status teleconference meeting on various installation/repair issues, more frequent if needed. The time will be mutually agreed upon. The Government is the only party that has the unilateral right to cancel or change a teleconference. The contractor will provide a toll free conference line. The contractor shall prepare the agenda and email report summarizing the discussion within one workday after completion.
14.5 Additional Meetings/Teleconferences. Additional meeting and teleconferences may be required based on issues that need to be addressed. The time will be mutually agreed upon. The contractor will provide a toll free conference line. The contractor shall prepare the agenda and email report summarizing the discussion within three workdays after completion.
15.0 Reporting Requirements. Contractor will be required to provide the following reports on the 5th workday of the month.
15.1 Monthly Inventory report at the physical level. Report must include (but not limited to) the following: contract number, call order number, hardware make, hardware model, serial number, memory, cores, sockets, processor speed, operating system, operating system version, operating system version date installed, physical location, (to include: site location, floor tile location, rack ID, server location, etc.), order date, installation date, and acceptance date)..
15.2 Weekly Order Summary. Report must include (but is not limited to) the following: Call order number, order received, valid order date, call order line number, CLIN, SLIN, description, Customer, , Project, quantity, required delivery, Technical POC, base price, extended price, estimated ship date, actual ship date, estimated delivery date, actual delivery, estimated install date, actual install, actual provision date, acceptance date, order status, and description.
15.3 Ad Hoc Reports. As required based upon Government requirements.
16.0 Security
16.1 Security. Comply with all applicable security directives, including the DoD Directive 8500.1, "Information Assurance (IA)"; DoD Instruction 8500.2, "Information Assurance (IA) Implementation"; 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).
16.2 Information Assurance. DoD and DISA are intensely aware of our adversaries' desires to exploit our networks and systems, and therefore takes system and network security very seriously. Our ability to monitor and protect systems is primarily focused on using the network capabilities to do so and consequently the majority of our efforts are network-based. With the exception of host-based security systems, virtually all other computing assets associated with security and network defense are considered to be processor assets are therefore expected to be covered under this contract.
16.3 Department of Defense (DoD) Directive 8500.1, Information Assurance, and DoD Instruction 8500.2, "Information Assurance (IA) Implementation requires that "all IA and IA-enabled IT products incorporated into DoD information systems shall be configured in accordance with DoD-approved security configuration guidelines." DISA Instruction 630-230- 31 assigns the DISA Deputy Director for Operations with the responsibility to develop and maintain Security Technical Implementation Guides (STIGs). These STIGs (or Addendum, as appropriate) serve as the security configuration guidelines required by DoDD 8500.1. DoDD 8500.1 has been supplemented with additional information concerning specific operating system environments including the Microsoft Windows NT, Windows 2000, Windows 2003, and Windows XP operating systems.
Additionally, all equipment that provides an information assurance function, such as SSL termination meet specific guidelines such as Federal Information Protection Standards (FIPS) 140-2, or National Institute of Standards and Technology (NIST) Common Criteria EAL-4 evaluation. The service provider and Government will work together to ensure that all equipment provided meets all required federal, DoD, and/or DISA standards as appropriate.
16.4 DISA utilizes classified and controlled unclassified information to accomplish mission objectives. Contractor personnel exposed to this level of information must protect the data through the use of the security features inherent to software loaded, strong authentication and physical constraints as outlined below. Any deviation from standard practices may compromise data resulting in harm to the government.
16.5 DISA operating facilities' security is multifaceted and implemented utilizing the layered approach. The traditional security requirements such as perimeters being patrolled, stationary guards assigned, approved access devices such as locks, card readers, badges, access logs and detection devices are physical controls implemented to deter unauthorized access. Information controls render a different challenge by protecting automated sensitive data and associated resources from unauthorized access. Accounts are established after registered personnel meet access and/or clearance levels necessary for position.
Through awareness training, directives and local policy contracted personnel are expected to comply with local security requirements upholding physical and information system security disciplines. When hardware is no longer required, the Government will ensure the media (tapes, hard drives, mass storage devices, etc.) is sanitized or destroyed in accordance with appropriate regulations. If the media cannot be sanitized and rendered to the unclassified level, the media may or may not be returned to the Contractor in an unusable state. This process is to ensure the protection of controlled both sensitive but unclassified and classified information. (SBU)
16.6 Data storage devices removed from the subsystems in this agreement must be certified to be processed in compliance with Assistant Secretary of Defense Memorandum, Subject: Disposition of Unclassified DoD Computer Hard Drives, dated June 4, 2001.
16.6.1 If data is saved across other data storage devices in such a manner that results in no intelligible information being recoverable from any single drive there is no requirement to overwrite, degauss or destroy the drive. The contractor must certify in writing that data is stored in such manner on the data storage devices.
16.6.2 If a removed hard drive is operable and is to be relocated on site, overwrite is not required.
16.6.3 If a removed hard drive is to be redirected to another site and is still operable or if the device is inoperable, the contractor shall certify in writing that the drive has been sanitized or disposed of in accordance with the Assistant Secretary of Defense Memorandum, Subject: Disposition of Unclassified DoD Computer Hard Drives, dated June 4, 2001.
16.7 IAW DoD Cybercom USB Flash Media Communication Tasking Order (CTO) 10-084, USB Flash Media/Thumb drive devices are prohibited in DoD. Contractors are prohibited for such use also, therefore contractors must ensure that USB Flash Media/Thumb drives devices are not required for any operations of this requirement.
16.8 Personnel under this contract may have maintenance responsibilities for and access to systems with a relatively high risk for causing damage to Government facilities, systems and/or data if compromised. All personnel performing on this contract must a have a minimum of a Secret clearance and an IT position sensitivity of IT-I. The minimum investigation required is a Single Scope Background Investigation (SSBI).
16.8.1 In accordance with DISA Memorandum, Subject: Requesting Investigations for Secret Eligibility and Information Technology I Access, 26 January 2009: Requests for investigative services for contract employees requiring Inf`ormation Technology 1 (IT-1) access and a Secret security clearance will be managed by the DISA Security Office. This change is necessitated due to the Defense Industrial Security Clearance Office (DISCO) under the direction of the Defense Security Service (DSS) is no longer accepting the Single Scope Background Investigation (SSBI) for contract positions requiring the IT-1/Secret eligibility. The DISA Security Office will review, submit and where possible, grant interim eligibility on the nominated contract employee.
16.8.2 Program managers of these contractual efforts will be required to substantiate the requirement for the investigation. Each program will fund the cost of the contract investigation, so due diligence is required to ensure only the proper amounts of investigations are submitted to meet mission needs. Contracting Officer Representatives (COR), Task Monitors (TM), or Security Managers will submit requests for investigative service to DISA Security (MPS6) utilizing the format provided at contract award.. MPS will work directly with organization Resource Managers to arrange reimbursement when the invoice for Personnel Security Investigations is received each month.
16.8.3 Upon receipt of the request for investigative service, the DISA Security Office will take on a servicing relationship of the contract employee within the Joint Personnel Adjudication System (JPAS) and initiate the investigative request. The DISA Security Office (MPS6) will review the submission and, when favorable, grant both the interim IT access and interim security clearance eligibility. The results of this will be recorded in JPAS and subsequently in CMIS. COR/TMs and Security Managers will follow all other established procedures for submitting the Visitor Access Requests (VARs) once access has been granted.
16.8.4 The contractor shall ensure that personnel accessing information systems have the proper and current information assurance certifications to perform information assurance functions in accordance with DoD 8570.01-M, Information Assurance Workforce Improvement Program.
16.9 ADPE Maintenance Records/DISA CSD Form 7: Records shall be completed in cooperation with site Service Desk personnel, for all maintenance actions including predictive, remedial, preventive maintenance, ECP, install, deinstall, or upgrade action. Records shall be completed using the attached DISA CSD Form 7 ATTACHMENT 7), or electronic equivalent. The completed report shall be returned to the Service Desk or for remote locations to the shift supervisor, prior to the technician departing the site. If the contractor fails to submit documentation at the time required, it may result in the Government withholding payment.
It may be supplied upon contract award. The “Instructions to Complete the ADPE Maintenance Record” lists the information to be entered into the fields by the OST/help desk personnel. Contractor CE personnel should review all fields on the DISA CSD Form 7 for accuracy before they sign the DISA CSD Form 7. Contractor CE personnel will receive a copy of the signed DISA CSD Form 7 before departing the site or upon conclusion of the service call where the machine is repaired and operating within OEM specifications. The contractor must coordinate with the managing site system administrator and have a valid Form 7 to perform any actions on contractor managed equipment on the machine room floor at any DISA site. This includes proactive maintenance events. The contractor must also correlate the site TMS ticket number with the contractors ticket/tracking number.
16.10 Additional Security Requirements. All personnel under this contract who are required to go to DISA Computing Sites to perform hardware maintenance are required to have a SECRET IT-Level I security clearance. In this regard, they shall be required to comply with applicable portions of the above referenced Security Program Directives. The DD254 will be attached with the RFP. Contractors shall have a fully adjudicated facility clearance prior to contract award.
17.0 Period of Performance
Period of performance is five (5) years with three (3), one-year renewal options for a total lifecycle of eight (8) years.
18.0 Definitions
18.1 After Hours: After Hours are defined as before 0600 local time, after 1800 local time, weekends and holidays.
18.2 Normal Business Hours: Normal Business Hours are defined as 0600-1800 local time.
18.3 Processor: The process of using technology to transfer information from point to point.
18.4 Processor Capabilities: Include, but are not limited to, hardware (including cabinets/racks/cabling), hardware maintenance, operating system software,VMWAre, as well as, any other software required for contractor solution to operate, and services to support the processor infrastructure associated with this contract remote access availability, the ability to access hardware and software equipment and management services to monitor and manage processor resources at DISA-owned and other approved processing locations.
18.5 Processor Equipment: Includes hardware (including cabinets/racks/cabling), hardware maintenance, operating system software, VMWare, as well as, any other software required for contractor solution to operate, and services to support the…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .