m2P1_J_6_Transition_Support_tasks_FINAL_8JUL2016.docx

Attachment J-6 Transition support tasks The Tasks 1 and 2 are notional sample tasks of potential workloads for migration to allow the Offeror to provide an estimated cost for transition support a Basis of Estimate (BOE) for each task for evaluation. The Government will evaluate the technical approach and cost factors shown in the BOEs. Tasks 3 through 7 are actual existing milCloud workloads that are scheduled to be transitioned to milCloud 2.0 as part of the Initial Operating Capability (IOC). The Offeror will provide a BOE for each task with estimated level of effort including the proposed number of labor hours by labor category required to perform a successful transition for each task from the current state to the proposed cloud environment. Note that the existing systems are subject to change in detail as the systems evolve, and the identified systems are also subject to replacement upon contract award. Fully burdened firm fixed prices by labor category will be established in the contract. Actual task orders for transition of IOC workloads will negotiated with the successful offeror after contract award.

If the offeror feels that some or all of the labor should be performed at the Consumer’s current location, they will define the hours for the tasks which must be performed at the Consumer’s location, and the hours that should be performed at the Offeror’s location or the DISA Cloud Hosting location.

The Offeror will also include in each BOE a priced list of CLINs/SLINs to meet the IaaS capacity required to support the systems in each task to include all compute, storage and required services.

Travel to the Consumer location will be performed using cost-reimbursable ODCs in accordance with standards identified in FAR Part 31 (aka the JTR). Offeror will identify the estimated travel by identifying the quantity of FTE/Days required for completeness and reasonableness evaluation purposes only. There shall be no travel required or funded for work performed at the DISA Cloud Hosting site, or Offeror’s location.

The Offeror shall propose intermediate level or grade support personnel to support the defined categories. Labor descriptions and skill levels are described in Attachment J-9 for reference. The Offeror may propose different labor categories or experience levels instead of, or in addition to those listed.

Each task description will define the current environment. If additional data would be required from the Consumer, the Offeror will make an assumed answer, and document the assumptions with the response. The Transition Support Task Order Response will provide a description of the work to be performed and the tools and methodology to be used, plus an estimate to perform the following tasks (if required):

A. Technical Analysis - Analyze the current environment to include network connectivity, server performance, virtualization requirements and application design B. Transition Program Plan - Develop plan to transition to cloud environment including resource capacity, funding assessment, architectural support, mitigation of workload or data portability issues, testing, risk planning, recommended server sizes, OS and application changes related to the target environment C. Virtualize - Transition all physical and virtual servers to images suitable for the target virtual format.

D. Extract, Transform and Load (ETL) of data stores, for migration to the infrastructure services, when applicable E. Migrate - Transport all images and data to the infrastructure services F. Import - Import or Export images and data into the Consumer’s purchased infrastructure services G. Turn-over - Ensure connectivity for Consumer management personnel to target servers H. Testing of DoD Consumer mission capabilities after migration I. Aid in understanding the use of service APIs, CLIs, and infrastructure service management consoles J. Support in using operational features such as machine image snapshotting and image libraries K. Support in Consumer IA accreditation efforts for their transitioned workloads L. Additional tasks as defined by the Offeror

Task 1 (Notional) Legacy application with physical servers This is an Notional example of an existing DoD legacy project with staff with a low level of technical knowledge. They will require Transition support for all phases of the transition. The application has a Private (.mil only) facing web tier containing two small Red Hat 6.x servers. The application must be available 24/7/365, and is not designed for elasticity. There are two application servers running Windows Server 2008 R2, and two clustered database servers running red Hat 6.x and using a shared database. All servers are currently rack mounted physical servers operating at the Consumer location. The application operates at a single site, with no COOP or failover to an external site. Standard backup is required to provide 24 Hour RTO, and 24 Hour RPO for all storage. Privileged administrative users are at a combination of .mil DoD and .com contractor sites.

Task 1

Existing Physical Servers

Object Storage

Task 1 Support Labor

Task 2 (Notional) Virtualized Legacy System Task 2 is an Air Force legacy system operating on Microsoft Hyper-V. It is in a small center on an Air Force base. The personnel are knowledgeable about virtualization and their application. They will require some support on all aspects of the transition. The application must be available 24/7. The developers want to add the ability to horizontally expand the Web and App tiers which is a capability of the application. This is to meet expected increased demand for the application during business hours, and to allow for surge processing in the event of a deployment. The Consumer wants to manage their own backup of the database. Failing servers will be restored from existing templates for OS and Application software. The Consumer plans to provide their own services including logging, VPN, CND and scanning from their existing datacenter via a lobe extension. The lobe extension will exist in the COLO (co-located network devices) at the site of the milCloud 2.0 instance. The COLO will be DISA designed and managed. Privileged administrative users are at .mil DoD sites. The application is impact level 5, and requires internal failover, and RPO and RTO of no more than 8 hours.

Task 2 Virtualized Legacy System

Task 2 Support Labor

Task 3 (IOC) IRIS Test System in RACE IRIS is a DISA Test system that recently transitioned from DISA’s RACE environment to milCloud 1.0. The following is a System Requirements Form (SRF) that was extracted from their transition request. IRIS has two servers.

Part 1 - Project Overview Project Identification

IRIS Legacy RACE Dev

8. Project Description – Describe project details, dependencies, and constraints below. Attach any relevant design specifications or documentation to this section.

The Mission Partner requested an estimate to detail the total cost support services provided with the milCloud Plus service offering rate for the legacy RACE PLD environment. The Mission Partner would order through the milCloud portal two (2) milCloud Central Processing Units (CPUs), 4 gigabytes (GB) of Random Access Memory (RAM) and 200 GBs of usable storage. The IRIS environment consists of two (2) development Virtual Operating Environments (VOEs)

9. System/Application Description

Test systems for DITCO

10. Operational Impact

Development System

|_| Classified |_|Sensitive |X| NIPRNet |_| SIPRNet |_| Mission Partner DAA Accredited Enclave (CDAE)

|X| IATT

|_| IATO

|_| ATO

|_| Not Accredited

DISA

|_| Configuration Management Plan |_| Risk Management Plan |_| Vulnerability Management Plan |_| Patch Management Plan |_| Incident Response Plan |_| Continuity of Operations Plan |_| Disaster Recovery Plan |_| DoD 8500.2 IA Control Review Location of Review:

|_| Application Security and Development Review Location of Review:AFNIC |_| Privacy Impact Assessment Location of Assessment:AFMC/A6 XI

29. Tool Compatibility

HBSS |X| Yes |_| No |_| Unknown ESM Software |_| Yes |_| No |_| Unknown

CDSP - DoDD O-8530.01 and in support of CJCSI 6510.01F and CJCSI 6211.02D, require all DoD information systems and networks that process, store, transmit, display, or receive DoD information to be aligned in writing to an accredited Tier II CDSP. The Mission Partner is required to obtain/maintain compliance with this requirement. DISA is able to provide this service or another provider can be used. In the case that another CDSP provider is chosen, a copy of the current SLA must be provided so that DISA analysts are able to provide TIPPER notifications the chosen CDSP.

CDSP POC

CDSP Email

Special Compliance Information (select all that apply)

|_| Unrestricted (unauthenticated) |_| Restricted (authenticated .com) |_| Private (access from .mil only) |_| Yes |_| No

42. Cyber Compliance

|_| Yes |_| No

Special Audits, Inspections, Assessments, and Tests (select all that apply)

Mission Partner Technical POC

Mission Partner Financial POC

Mission Partner IA POC

Service Provider Team Lead

Service Provider Project Manager

Service Provider Technical Lead

Service Provider Customer Account Rep (CAR)

Service Provider IA Technical Advisor

Service Provider Network Lead

Service Provider Software Engineer

Target Dates Initial Operation Environment (IOE) Date – date that Operating Environments (OEs) are turned over to the application administrators for application load Initial Operating Capability (IOC) Date – date that OEs are configured for production users

Risk Assessment Note: IA risk can only be determined by the IA Technical Advisor

|_| High |_| Medium |X| Low |_| High |_| Medium |X| Low |_| High |_| Medium |X| Low

57. Enter Details of Any “High” or ‘Medium” Risks Noted:

N/A

Part 2 - Implementation and Cutover Support Requirements

1. Implementation Contacts

Mission Partner Lead Technical POC

Mission Partner Lead Management POC (Authority to approve changes)

Vendor or Integrator SME

Other Implementation POC (specify)

2. Migration Requirements

(e.g., DB Export, Flat File, OVA Image) File Transmission Method (Offline Copy, Online Copy (SFTP), Array-to-Array Replication, Application Replication) Migration Method (Import, Overlay, Mirror, OVA)

3. Cutover Requirements

Describe the cutover window in terms of length and timing constraints:

Describe the Mission Partner, integrator, and vendor resources necessary to support cutover:

Describe any system-specific post-cutover acceptance criteria:

Describe any post-cutover parallel processing requirements:

4. Performance Metrics

Provide any performance metrics that must be attained for systems migrating to the Service Provider:

5. Global Service Desk Level 1 Support Information

Approximate number of concurrent end-users:

Approximate Service Desk contact volume and frequency:

Part 3 - Technical Requirements

1. Mission Partner Disposition – Which of these statements best describes the Partner’s view of their technical requirements?

The Mission Partner is providing a detailed specification for computing infrastructure that they expect to deliver without modification.

The Mission Partner is providing detailed technical requirements based on an existing environment but acknowledges the design may not be optimal for Cloud hosting and is willing to engage the Cloud Service Provider to explore design alternatives.

The Mission Partner is providing general technical description and requires the Cloud Service Provider technical assistance to define technical requirements.

Other (fill in here):

N_RUJ03R_70_131

N_RUJ03R_70_163

2. OE Storage Requirements – Specify the storage that is required by each OE (usable storage in GB)

Object Storage – Not tied to specific server

Total Usable Storage Required (in GBs):

3. Web Interfaces – Identify URLs required and their attributes Public – Any service intended to provide unclassified and non-sensitive information accessible from outside the NIPRNet, to include anonymous access.

Restricted – Any service intended to be accessible from the Internet and serves sensitive information to a limited set of users. Access controls are in place to limit the user set who can access the service.

Private – Any service meant to be accessed only from the NIPRNet or SIPRNet, respectively (.mil only).

(see definitions above) Load-balanced to Multiple Web Servers (Yes/No)

4. External System Communication Requirements – List the OEs that require communication with any external system. Specify the ports and protocols used by each. This does not include external access for administration by privileged users.

NA

5. Internal System Communication Requirements – List the OEs that require communication with other OEs within the enclave. Specify the ports and protocols used by each.

tbd

6. Software Requirements – List all application software, tools and accessories. Do not include Cloud Service Provider-provided Enterprise Systems Management (ESM) software.

tbd

7. Open Source Software Requirements – List all open source software used. For open source, indicate whether or not the software has been DAA-approved. List additional information (i.e. licensing, vendor support, etc.) in the Notes column.

Software Vendor Software Name Version Information

Yes |_| No|_|

Yes |_| No|_|

Yes |_| No|_|

Yes |_| No|_|

Yes |_| No|_|

8. User Authentication Requirements

Does user authentication / authorization require access to a remote resource (e.g., LDAP, AD)? |_| Yes |_| No

If Yes, who will manage the authentication / authorization database? .

9. Networking & Security

Describe any specific data protection requirements (e.g., data at rest) specified by the data owner.

N/A

Describe any interconnection requirements among DoD applications operating at different classification levels (e.g., SIPRNet to NIPRNet or vice versa).

Describe any system-to-system interfaces with government agencies, commercial companies, foreign countries, etc.

N/A

Characterize anticipated aggregate bandwidth requirements (data center inbound/outbound).

Load Balancing: Describe any local or global application and/or server load balancing requirements.

10. Local High Availability Requirements – Does the system require any specific local high availability feature for any specific OEs or functions (e.g., clustering, Oracle RAC)?

|_| Yes |X| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., active, passive, RAC) below:

11.

Remote or Second Site High Availability Requirements – Does the system require remote or second site high availability feature for any specific OEs or functions (e.g., remote failover, clustering, Oracle RAC)?

|_| Yes |X| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., synchronous, asynchronous, RAC) below:

Part 4 - Standard and Optional Rate-Based Services

1. Core Services – Every workload hosted in milCloud 2.0 is based on the amount of Compute capacity.

Describe any requested deviations from these core services:

2. Optional CSP Services –The below services may be acquired from the CSP These may have prerequisites in terms of connectivity and root control of the OS. Review and check any requested optional services:

3. Optional Value Add Services –The below services may be acquired from DISA. These may have prerequisites in terms of connectivity and root control of the OS. These may include any of the “Optional” service shown below. Review and check any requested optional services:

Include any comments or relevant information related to the selected optional services above:

4. Conditional Services – Conditional services may be required depending upon the optional services selected. Review and check any applicable conditional services that apply:

Include any comments or relevant information related to the selected conditional services above:

5. Service Continuity – If remote site COOP support is required, please select one of the options below. Descriptions ar ebased on DISA service levels for reference. These services may be application dependent depending on the level of automation required:

(RTO = 5 days, RPO = 7 days) – MAC III applications only

(RTO = 5 days, RPO = 8 hours) – MAC III applications only

(RTO = 24 hours, RPO = 8 hours)

(RTO and RPO = 8 hours)

(RTO = 30 minutes, RPO = 1 Sec)

Note any special considerations related to your Service Continuity requirement here and provide more detailed specifications in the Non-Standard Requirements section, if applicable:

Part 5 - Non-Standard Requirements Fulfillment of non-standard requirements are generally not included in the Service Provider’s published server and storage rates and entail additional design and integration efforts, special considerations/approvals (waivers), and/or long procurement lead times.

1. Non-Standard Configurations or Mission Partner-Provided Items – Specify non-standard or Mission-Partner-provided hardware that must be deployed at a DECC in support of this system.

|_| Yes |_| No

|_| Yes

|_| Yes

|_| Yes

|_| Yes

|_| Yes

2. Non-Standard Support Requirements – Explain any non-standard operations or support requirements. (e.g., any SME labor or non-standard support functions.

3. Non-Standard Communications or Network Requirements – Explain any non-standard network or communications requirements. (e.g., any deviation from the Service Provider enclave designs, exceptional bandwidth, latency or access requirements, etc. Include diagrams if available.)

4. Non-Standard Other – Explain any non-standard unusual, unique or exceptional requirements that do not fit into the previous categories.

5. Additional Documentation – Attach and identify in the space below any documents that support the specification of non-standard requirement(s) noted in this section:

Task 3 IRIS Support Labor

Task 4 (IOC) PSD Development and Test Systems PSD is two environments, Development and Test, that have recently transitioned from RACE to two separate VDCs in milCloud 1.0. The data below has been extracted from their transition requests. There are separate support teams for each environment, and they are billed separately. Transition may be billed on a single Task Order.

Part 1 - Project Overview Project Identification

PSD Legacy RACE Dev and Test

65. Project Description – Describe project details, dependencies, and constraints below. Attach any relevant design specifications or documentation to this section.

The Mission Partner requested an estimate to detail the total cost of support services provided with the milCloud Plus service offering rate for the PSD Legacy Applications. The Mission Partner would order through the milCloud portal seven (7) milCloud Central Processing Units (CPUs), 18 gigabytes (GB) of Random Access Memory (RAM) and 1220 GBs of usable storage. The PSD Legacy Applications Development environment consists of three (3) development Virtual Operating Environments (VOEs). To meet the requirements of this request, the Service Provider would provide the services outlined in Enclosure 1 with the milCloud Plus service rate to three (3) development VOEs The Mission Partner requested an estimate to detail the total cost support services provided with the milCloud Plus service offering rate for the PSD Legacy Test RACE/milCloud environment. The Mission Partner would order through the milCloud portal 12 milCloud Central Processing Units (CPUs), 26 gigabytes (GB) of Random Access Memory (RAM) and 2,600 GBs of usable storage. The PSD Legacy Test environment consists of five (5) test and development Virtual Operating Environments (VOEs). To meet the requirements of this request, the Service Provider would provide the services outlined in Enclosure 1 with the milCloud Plus service rate to five (5) test and development VOEs

66. System/Application Description

Development and Test enclaves

67. Operational Impact

Development and Test Systems

|_| Classified |_|Sensitive |X| NIPRNet |_| SIPRNet |_| Mission Partner DAA Accredited Enclave (CDAE)

|_| IATT

|_| IATO

|_| ATO

|X| Not Accredited Development system – VPN access only

|_| Configuration Management Plan |_| Risk Management Plan |_| Vulnerability Management Plan |_| Patch Management Plan |_| Incident Response Plan |_| Continuity of Operations Plan |_| Disaster Recovery Plan |_| DoD 8500.2 IA Control Review Location of Review:

|_| Application Security and Development Review Location of Review:AFNIC |_| Privacy Impact Assessment Location of Assessment:AFMC/A6 XI

86. Tool Compatibility

HBSS |X| Yes |_| No |_| Unknown ESM Software |_| Yes |_| No |_| Unknown

CDSP - DoDD O-8530.01 and in support of CJCSI 6510.01F and CJCSI 6211.02D, require all DoD information systems and networks that process, store, transmit, display, or receive DoD information to be aligned in writing to an accredited Tier II CDSP. The Mission Partner is required to obtain/maintain compliance with this requirement. DISA is able to provide this service or another provider can be used. In the case that another CDSP provider is chosen, a copy of the current SLA must be provided so that DISA analysts are able to provide TIPPER notifications the chosen CDSP.

Special Compliance Information (select all that apply)

|_| Unrestricted (unauthenticated) |_| Restricted (authenticated .com) |_| Private (access from .mil only) |_| Yes |_| No

99. Cyber Compliance

|_| Yes |_| No

Special Audits, Inspections, Assessments, and Tests (select all that apply)

Mission Partner Technical POC

Mission Partner Financial POC

Mission Partner IA POC

Service Provider Team Lead

Service Provider Project Manager

Service Provider Technical Lead

Service Provider Customer Account Rep (CAR)

Service Provider IA Technical Advisor

Service Provider Network Lead

Service Provider Software Engineer

Target Dates Initial Operation Environment (IOE) Date – date that Operating Environments (OEs) are turned over to the application administrators for application load Initial Operating Capability (IOC) Date – date that OEs are configured for production users

Risk Assessment

|_| High |_| Medium |X| Low |_| High |_| Medium |X| Low |_| High |_| Medium |X| Low

114. Enter Details of Any “High” or ‘Medium” Risks Noted:

N/A

6. Implementation Contacts

Mission Partner Lead Technical POC

Mission Partner Lead Management POC (Authority to approve changes)

Vendor or Integrator SME

Other Implementation POC (specify)

7. Migration Requirements

(e.g., DB Export, Flat File, OVA Image) File Transmission Method (Offline Copy, Online Copy (SFTP), Array-to-Array Replication, Application Replication) Migration Method (Import, Overlay, Mirror, OVA)

N_DIT01R_65_196

1,000

8. Cutover Requirements

Describe the cutover window in terms of length and timing constraints:

Describe the Mission Partner, integrator, and vendor resources necessary to support cutover:

Describe any system-specific post-cutover acceptance criteria:

Describe any post-cutover parallel processing requirements:

9. Performance Metrics

Provide any performance metrics that must be attained for systems migrating to the Service Provider:

10. Global Service Desk Level 1 Support Information

Approximate number of concurrent end-users:

Approximate Service Desk contact volume and frequency:

12. Mission Partner Disposition – Which of these statements best describes the Partner’s view of their technical requirements?

The Mission Partner is providing a detailed specification for computing infrastructure that they expect to deliver without modification.

The Mission Partner is providing detailed technical requirements based on an existing environment but acknowledges the design may not be optimal for Cloud hosting and is willing to engage the Cloud Service Provider to explore design alternatives.

The Mission Partner is providing general technical description and requires the Cloud Service Provider technical assistance to define technical requirements.

Other (fill in here):

N_DIT01R_65_131

N_DIT01R_65_165

N_dit01r_65_196

N_DIT02R_78_195

N_DIT02R_78_227

N_DIT02R_78_162

N_DIT02R_78_194

N_DIT02R_78_226

13. OE Storage Requirements – Specify the storage that is required by each OE (usable storage in GB)

Object Storage – Not tied to specific server

Total Usable Storage Required (in GBs):

14. Web Interfaces – Identify URLs required and their attributes Public – Any service intended to provide unclassified and non-sensitive information accessible from outside the NIPRNet, to include anonymous access.

Restricted – Any service intended to be accessible from the Internet and serves sensitive information to a limited set of users. Access controls are in place to limit the user set who can access the service.

Private – Any service meant to be accessed only from the NIPRNet or SIPRNet, respectively (.mil only).

(see definitions above) Load-balanced to Multiple Web Servers (Yes/No)

15. External System Communication Requirements – List the OEs that require communication with any external system. Specify the ports and protocols used by each. This does not include external access for administration by privileged users.

NA

16. Internal System Communication Requirements – List the OEs that require communication with other OEs within the enclave. Specify the ports and protocols used by each.

tbd

17. Software Requirements – List all application software, tools and accessories. Do not include Cloud Service Provider-provided Enterprise Systems Management (ESM) software.

tbd

18. Open Source Software Requirements – List all open source software used. For open source, indicate whether or not the software has been DAA-approved. List additional information (i.e. licensing, vendor support, etc.) in the Notes column.

Software Vendor Software Name Version Information

Yes |_| No|_|

Yes |_| No|_|

Yes |_| No|_|

Yes |_| No|_|

Yes |_| No|_|

19. User Authentication Requirements

Does user authentication / authorization require access to a remote resource (e.g., LDAP, AD)? |_| Yes |_| No

If Yes, who will manage the authentication / authorization database? .

20. Networking & Security

Describe any specific data protection requirements (e.g., data at rest) specified by the data owner.

N/A

Describe any interconnection requirements among DoD applications operating at different classification levels (e.g., SIPRNet to NIPRNet or vice versa).

Describe any system-to-system interfaces with government agencies, commercial companies, foreign countries, etc.

N/A

Characterize anticipated aggregate bandwidth requirements (data center inbound/outbound).

Load Balancing: Describe any local or global application and/or server load balancing requirements.

21. Local High Availability Requirements – Does the system require any specific local high availability feature for any specific OEs or functions (e.g., clustering, Oracle RAC)?

|_| Yes |X| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., active, passive, RAC) below:

22.

Remote or Second Site High Availability Requirements – Does the system require remote or second site high availability feature for any specific OEs or functions (e.g., remote failover, clustering, Oracle RAC)?

|_| Yes |X| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., synchronous, asynchronous, RAC) below:

6. Core Services – Every workload hosted in milCloud 2.0 is based on the amount of Compute capacity.

Describe any requested deviations from these core services:

7. Optional CSP Services –The below services may be acquired from the CSP These may have prerequisites in terms of connectivity and root control of the OS. Review and check any requested optional services:

8. Optional Value Add Services –The below services may be acquired from DISA. These may have prerequisites in terms of connectivity and root control of the OS. These may include any of the “Optional” service shown below. Review and check any requested optional services:

Include any comments or relevant information related to the selected optional services above:

9. Conditional Services – Conditional services may be required depending upon the optional services selected. Review and check any applicable conditional services that apply:

Include any comments or relevant information related to the selected conditional services above:

10. Service Continuity – If remote site COOP support is required, please select one of the options below. Descriptions ar ebased on DISA service levels for reference. These services may be application dependent depending on the level of automation required:

(RTO = 5 days, RPO = 7 days) – MAC III applications only

(RTO = 5 days, RPO = 8 hours) – MAC III applications only

(RTO = 24 hours, RPO = 8 hours)

(RTO and RPO = 8 hours)

(RTO = 30 minutes, RPO = 1 Sec)

Note any special considerations related to your Service Continuity requirement here and provide more detailed specifications in the Non-Standard Requirements section, if applicable:

Fulfillment of non-standard requirements are generally not included in the Service Provider’s published server and storage rates and entail additional design and integration efforts, special considerations/approvals (waivers), and/or long procurement lead times.

6. Non-Standard Configurations or Mission Partner-Provided Items – Specify non-standard or Mission-Partner-provided hardware that must be deployed at a DECC in support of this system.

|_| Yes

|_| Yes

|_| Yes

|_| Yes

|_| Yes

|_| Yes milCloud 2.0 SRF Template Version FY16.0 – Jun 2016

7. Non-Standard Support Requirements – Explain any non-standard operations or support requirements. (e.g., any SME labor or non-standard support functions.

8. Non-Standard Communications or Network Requirements – Explain any non-standard network or communications requirements. (e.g., any deviation from the Service Provider enclave designs, exceptional bandwidth, latency or access requirements, etc. Include diagrams if available.)

9. Non-Standard Other – Explain any non-standard unusual, unique or exceptional requirements that do not fit into the previous categories.

10. Additional Documentation – Attach and identify in the space below any documents that support the specification of non-standard requirement(s) noted in this section:

Task 4 Support Labor for PSD Development and Test Systems

Task 5 (IOC) CMIS Development and Test Systems Task 5 is for the CMIS program Development and Test systems that were recently implemented in milCloud 1.0. Development and Test systems are in a single VDC in milCloud, but are logically separated except as noted in the following SRF document.

Part 1 - Project Overview Project Identification

122. Project Description – Describe project details, dependencies, and constraints below. Attach any relevant design specifications or documentation to this section.

Move the existing CMIS basic milCloud VDC (0280u) to the milCloud 2.0 service

123. System/Application Description

Test system for CMIS

124. Operational Impact

CMIS is the only tool that DISA uses to track human resources management information to include security, training, travel, and facilities information.

|_| Classified |X|Sensitive…