AMD_08.pdf

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT

Except as provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. NAME AND TITLE OF SIGNER (Type or print)

30-105-04EXCEPTION TO SF 30

APPROVED BY OIRM 11-84

STANDARD FORM 30 (Rev. 10-83) Prescribed by GSA

FAR (48 CFR) 53.243

a. The purpose of this amendment is to extend the proposal suspense date from 22 April 2016 to the new date of 27 May 2016.

b. This amendment also:

- revises Section L of the Solicitation;

- changes the Delivery Date from 30 June 2016 to the new date of 12 September 2016;

- incorporate updated FRD and Q&A attachments.

c. See Summary of Changes.

1. CONTRACT ID CODE PAGE OF PAGES

J 1 7

16A. NAME AND TITLE OF CONTRACTING OFFICER (Type or print)

16C. DATE SIGNED

BY 14-Apr-2016

16B. UNITED STATES OF AMERICA15C. DATE SIGNED15B. CONTRACTOR/OFFEROR

(Signature of Contracting Officer)(Signature of person authorized to sign)

8. NAME AND ADDRESS OF CONTRACTOR (No., Street, County, State and Zip Code) X W91RUS-16-R-0002

X 9B. DATED (SEE ITEM 11)

21-Dec-2015

10B. DATED (SEE ITEM 13)

9A. AMENDMENT OF SOLICITATION NO.

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

X The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offer X is extended, is not extended.

Offer must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended by one of the following methods:

(a) By completing Items 8 and 15, and returning 1 copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted;

or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN

REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified.

12. ACCOUNTING AND APPROPRIATION DATA (If required)

13. THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACTS/ORDERS.

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE

CONTRACT ORDER NO. IN ITEM 10A.

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.103(B).

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

D. OTHER (Specify type of modification and authority)

E. IMPORTANT: Contractor is not, is required to sign this document and return copies to the issuing office.

14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

10A. MOD. OF CONTRACT/ORDER NO.

2. AMENDMENT/MODIFICATION NO. 5. PROJECT NO.(If applicable)

6. ISSUED BY

3. EFFECTIVE DATE

13-Apr-2016

CODE

ACC-APG

MR. DANIEL OCTAVIANO 2133 CUSHING ST BLDG 618

FT HUACHUCA AZ 85613

W91RUS 7. ADMINISTERED BY (If other than item 6)

4. REQUISITION/PURCHASE REQ. NO.

CODE

See Item 6

FACILITY CODECODE

EMAIL:TEL:

W91RUS-16-R-0002

SECTION SF 30 BLOCK 14 CONTINUATION PAGE

SUMMARY OF CHANGES

SECTION SF 1449 - CONTINUATION SHEET

SOLICITATION/CONTRACT FORM

The required response date/time has changed from 22-Apr-2016 10:00 AM to 27-May-2016 10:00 AM.

DELIVERIES AND PERFORMANCE

The following Delivery Schedule item for CLIN 0001 has been changed from:

DELIVERY DATE QUANTITY SHIP TO ADDRESS DODAAC

30-JUN-2016 N/A

FOB: Destination

To:

DELIVERY DATE QUANTITY SHIP TO ADDRESS DODAAC

12-SEP-2016 0 N/A

FOB: Destination

TABLE OF CONTENTS

The Table of Contents has changed from:

Exhibit/Attachment Table of Contents

DOCUMENT TYPE DESCRIPTION PAGES DATE

Attachment J.1 Attachment J.1 FRD 35 18-DEC-2015 to:

Exhibit/Attachment Table of Contents

DOCUMENT TYPE DESCRIPTION PAGES DATE

Attachment J.2 J.2 FRD Rev 1 35 29-MAR-2016 Attachment J.3 J.3 Q&A as of 160413 32 13-APR-2016

The following have been added by full text:

SECTION L (REV 5)

Section L - Instructions, Conditions and Notices to Bidders

1. Instructions for Written Submittals: The Offeror shall submit its offer, individually titled, as set forth below via email to the Contract Specialist, Dan Octaviano, daniel.j.octaviano.civ@mail.mil no later than 10:00 AM (MST) 27 May 2016. Due to enterprise email file size restrictions, the Offeror may submit as separate emails.

It is requested that all questions pertaining to this solicitation and its attachments are sent in a Microsoft Word 2007 document via e‐mail to, daniel.j.octaviano.civ@mail.mil no later than 1:00 pm on 20 January 2016. The applicable Statement of Objectives (SOO) and/or Functional Requirements Document (FRD) paragraph number and solicitation reference shall precede all questions.

2. Proposal submission shall be as follows:

VOLUME

NUMBER CONTENTS

MAXIMUM

PAGES TITLE/FORMAT

1 GENERAL* N/A GEN1.DOC/GEN1.PDF

2 TECHNICAL 10 MS1.DOC

3 PRICE PROPOSAL** N/A PRICE.XLS/COST1.DOC

PAST PERFORMANCE

SUMMARY *** PAST1.DOC

*For any documents that need to be scanned and submitted as part of the proposal (i.e., SF 33 cover page, documents with signatures), ".PDF" format as prescribed above is encouraged, with the remaining narrative portions submitted as ".DOC" format.

**Narrative portion of the Price Proposal shall be submitted in ".DOC" format, and supporting price information for Schedule B (i.e., individual breakout with loadings and formulas) shall be submitted in ".XLS". During the evaluation, the Government may need to manipulate the worksheets, so worksheets should not be write protected. If they are write‐protected, then the offeror shall provide the Government with the write‐protection password.

***Past Performance Summary is limited to three pages per referenced contract.

a. The Technical Support Section must not contain any reference to the proposed costs/price.

b. Page Limitations & File Format: The Technical Support Section shall be limited to ten (10) pages. This is exclusive of Cover, Title Page, Table of Contents, and Table of Figures. The Technical Support section shall be submitted in Microsoft Word. The Pricing section shall be submitted in contractor’s own format using Microsoft Excel for calculations and Microsoft Word for any narrative. For the electronic submission, Microsoft Office 2007 products shall be used (acceptable MS Excel file extensions are .xls or .xlsx and acceptable MS Word file extensions are .doc or .docx).

c. The term “pages” includes pullout drawings, tables, diagrams, charts, indices, and tables. Paper size shall be 8‐ 1/2 x 11 inches, one sided typed. Print shall be single‐spaced with one‐inch margins on each side (top, bottom, left, right). Tables, charts, graphics, drawings, and diagrams will have a minimum font size of 10 point. All other narrative shall have a minimum font size of 12 point. Pullout drawings will be numbered and counted as multiple pages in relation to the 8‐1/2 x 11 inch size limitation. The pages composing the complete Technical Support proposal shall be numbered consecutively without regard to individual sub‐factors. Information not contained within the above limitations will not be evaluated.

d. The offeror shall include a statement indicating whether or not the Offeror intends to make use of any proprietary or patent information. In the event that use of such information is anticipated, the specific areas of use by the Offeror and its subcontractors must be clearly defined, including whether limited or unlimited rights are applicable. The offeror shall indicate the price to the Government for acquisitions of each and all proprietary information identified in the proposal.

e. The Offeror must submit a complete response to this solicitation using the sequence and format instructions provided in section 4. All information pertaining to the Technical and Price sections, shall be confined to the appropriate proposal section in order to facilitate independent evaluation. Proposals shall be clear and concise, logically assembled (with all pages appropriately numbered) and indexed and cross‐indexed to applicable parts of the Performance Work Statement or Request for Proposal, as appropriate. To reduce proposal size, the Offeror shall confine submission to essential matters sufficient to define the proposal, and provide an adequate basis for evaluation. No price information shall be presented in any part of the proposal except the price proposal. Proposal sections shall not contain classified data. NO ZIPPED FILES are permitted.

3. Submittal Contents (Volume 1 – General):

Proposal Transmittal Letter. A letter formally transmitting the proposal shall include the following:

a. Statement of Compliance. The Offeror shall include a statement indicating complete compliance with the solicitation, or detailed analysis of any objections, exceptions, contingencies, or additions.

b. Proprietary Information. The Offeror shall include a statement indicating whether the Offeror intends to make use of any proprietary or patent information.

c. Joint Venture/Teaming Arrangements. The Offeror shall provide, if applicable, a summary describing the Joint Venture/Teaming Arrangement established for this RFP and documentation evidencing the legal relationship among the joint venture/teaming parties.

d. Disclosure of Potential Organizational Conflicts of Interest. The Offeror shall disclose complete information of any work performed by their company that is in any way associated with the contemplated acquisition or which could result in a potential organizational conflict of interest.

e. Solicitation Documents. An authorized official of the firm shall sign the SF 1449. PDF versions of the signed documents shall be submitted as part of the electronic submissions. No changes of alterations shall be made to these sections of the solicitation. Offeror shall complete all the fill‐ins and signature blocks for the RFP items indicated below.

i. Section A. Standard Form 1449 (SF 1449), Solicitation, Offer and Award for Commercial Items. The Offeror shall submit a completed and signed SF1449.

ii. Representations, Certifications and Other Statements of Offerors (FAR representations, certifications and other statements of) shall be submitted on‐line in accordance with solicitation provision 52.204‐8.

iv. DFARS representations, certifications and other statements of Offerors shall be included with the solicitation documents and 252.209‐7999.

4. Factor 1 –Technical (Volume 2): This section shall be sufficiently specific, detailed, and complete as to demonstrate clearly and fully that the Offeror has a thorough understanding and knowledge of the complexities inherent in the development of this technical solution. Statements that the Offeror understands, can, or will perform the requirements of the SOO/FRD without supporting information or narratives are inadequate.

Paraphrasing the SOO/FRD or parts thereof, is similarly inadequate, as are phrases such as “standard procedures will be employed” or “well‐known techniques will be used.”

This section shall be written such as to enable evaluators to make a thorough evaluation as to whether the solution proposed adequately respond to the specific Government requirements. This part shall indicate the contractor’s capability in meeting the requirements by providing the information required below. Proposal shall be presented in narrative format, in a clear and logical manner. It must be confined to essential matters sufficient to permit a thorough analysis.

a. Technical Approach: The technical approach should identify the methodology and analytical techniques you will use to fulfill the requirements for each of the three subfactor functional areas. The technical approach shall include quality control. Proposals shall address the following areas:

Subfactor 1 – Integrated Solution. The – Integrated Solution evaluation provides an assessment of the offeror’s capability to satisfy the government’s requirements. To be rated “acceptable” an offeror’s proposal will demonstrate their understanding of and its ability to execute the functional requirements described Functional Requirement’s document as outlined below:

1. Pooled resources. The offeror’s solution will have the ability to execute flexible pooling of computing (processor and memory), storage, networking, and software resources. The offeror’s solution will have computing, storage, and network resources grouped in the same infrastructure environment to allow for reallocation of those resources on demand. This pooling helps deliver greater utilization and efficiency and is powered by virtualization, which abstracts the platform from the physical infrastructure. Multiple customers or multiple organizational units can share pooled resources, resulting in higher resource utilization and efficiency for both planners and users.

2. Customer Self-service. The solution will enable provisioning of basic resources for a customer such as services, virtual machines and user accounts without needing IT support intervention.

3. Usage Monitoring and auditing. The offeror’s solution will have the ability to capture metrics on resource consumption, report on installed services, and record data for comparative baseline analysis will aid in the efficient management of the enterprise across multiple sites.

4. Converged/Hyper-converged architecture goals. The offeror must have:

a. Support for multiple diverse workloads

b. Full end-to-end high-availability

c. 100% virtualization

d. 100% automation

e. Self Service Portal for Administration and Guests

f. Sub-system scale-out for the following:

1. Compute

2. Storage

3. Networking

g. Hardware platform independence

h. Just-in-time hardware provisioning

i. Hypervisor managed from a centralize location

1. Hypervisor is able to be managed by other vendor hypervisor

2. Hypervisor dynamic resource allocation

3. Rapid and High elasticity for adding VM’s

5. Faster deployment. The offeror must provide end-to-end architectural and deployment guidance. The offeror’s solution must provide enhanced functionality and automation through deep knowledge of infrastructure. The offeror’s solution must have integrated management for VM and infrastructure deployment at the enterprise level.

6. Shipment of Single Integrated System. The offer must provide a single integrated system in a shipment per installation site.

7. Lower total cost of ownership. The offeror must provide near-zero downtime with exceptional fault tolerance and high availability. The offeror must provide significant reduction in power, space and HVAC required for their solution versus traditional server centric solutions.

8. Elasticity and the Perception of infinite capacity. The offeror’s solution must provide that from the user’s perspective, services should appear to have infinite capacity. End users can consume as much or as little of the service as needed, just as they consume electricity. This principle helps achieve greater balance between the cost of unused capacity and the desire for agility. The offeror’s solution must include the ability to add new resources and services that is flexible and customizable to each organization’s mission need. Operations can better handle surging demands and peak usage through the tailoring of resources from computing power, virtual machines, storage, and bandwidth utilization.

9. Perception of continuous availability. The offeror’s solution must provide that from the user’s perspective, services should always be available when needed. The consumer should never experience an interruption in IT services, even if failures occur within the cloud infrastructure. The offeror must provide the ability to achieve this continuous availability, the private cloud architecture must deliver a highly automated environment in which infrastructure redundancies, such as failover clustering, are complemented by intelligent automation and management capabilities.

10. Minimum specifications. The offeror’s solution must provide the following minimal specifications:

a. Compute.

a. CPU: 500 Cores

b. RAM: 10 TB

c. IOPs: 175K

d. Network 10 GbE – 3 Total (2 for all traffic, 1 for management)

e. TPM encryption 2.0 or later

b. Storage:

a. Array: Shared array with cloud fabric, 400 TB

b. Storage connectivity: Connectivity for all hosts with host and switch redundancy

c. Network:

a. Ports: 10 GbE connectivity

b. Sufficient 10 GbE connectivity/port density to support all hosts with host and switch redundancy, support for VLANs(tagging, truncking, etc.)

Subfactor 2 – Implementation/Interoperability. The Implementation/interoperability evaluation provides an assessment of the offeror’s capability to satisfy the government’s requirements. To be rated “acceptable” an offeror’s proposal will demonstrate their understanding of and its ability to perform implementation at each site and post implementation tasks as outlined below:

1. Reduced risk. The offer must provide documentation to ensure that the equipment is tested end-to-end interoperability for computing, storage, and networking. The offeror’s solution must have a high degree of service availability through automated load balancing.

2. Implementation. The offeror must deliver, configure and integrate into the site architecture a solution to include site network connectivity, training and physical setup. Management of the virtual capacity will be performed by the Theater Regional Cyber Centers (RCC). The offeror must provide sufficient connectivity, configuration, documentation and training for the RCCs to accept responsibility for the solution.

3. Integration. The offeror must provide the ability to integrate both at the hardware and software level with currently implemented solutions within the enterprise. This includes but is not limited to JRSS, NETOPs toolset, Active Directory and Microsoft System Center 2012r2.

4. Interoperability. The offeror must provide the ability to operate with other deployed solutions within the Army to form a seamless view of virtual environment regardless of the hardware vendors in support of the Software defined infrastructure. This includes but is not limited to the ability to see storage from different vendors and present it to the environment as a usable resource.

Subfactor 3 - Support. The Support evaluation provides an assessment of the offeror’s capability to satisfy the government’s requirements. To be rated “acceptable” an offeror’s proposal will demonstrate their understanding of and its ability to provide support for the fielded solution as outlined below:

1. Warranty. The offeror must provide a warranty for the hardware to include next business day replacement of failed components for a minimum of 5 years.

2. Any supporting licenses not otherwise included to the government under separate agreements will be provided by the offeror.

NOTE: DO NOT submit a Quality Control Plan with your proposal. A comprehensive Quality Control Plan supporting the RFQ requirements will be required after contract award.

5. Factor 2 ‐‐ Price Proposal Section (Fixed Price with Reimbursable Line Items) (Volume 3): Offerors shall submit pricing for all Contract Line Item Numbers (CLINs) as formatted in SF1449 continuation sheet. This part shall include a spreadsheet in the contractor’s own format that details the labor calculation of its proposed monthly fixed prices for services. The Offeror shall submit pricing for each Contract Line Item Number (CLIN) which requires unit prices in order to be considered for award. The Offeror shall submit the total price for CLINs as formatted in SF1449 continuation sheet. The Offeror shall enter the proposed unit pricing in U.S. Dollars (rounded to the nearest cent and no more than 2 decimal places).

6. Factor 3 ‐‐ Past Performance (Volume 4): Submit a narrative no more than three pages describing up to three relevant contracts that are similar in size, scope, and complexity that you have performed as a prime contractor or subcontractor during the last three years. The contractor will demonstrate its experience by current and recent performance of contracts for customers such as Federal Government, agencies of State and local government, or commercial customers. Information pertaining to each of the contracts shall be provided (e.g., description of service, type of contract, period of performance, contract number and/or name, dollar value).

The following have been deleted:

SECTION L (REV 4)

(End of Summary of Changes)

FOR OFFICIAL USE ONLY

iFOR OFFICIAL USE ONLY

NETCOM

Global Enterprise Fabric (GEF) Functional

Requirements Document (FRD)

Version 1.6

29 March 2016

This document is not to be distributed or changed without express permission from the Network Enterprise Technology Command (NETCOM). This document contains information EXEMPT FROM MANDATORY DISCLOSURE under the Freedom of Information Act (FOIA). Exemption 5 applies (internal advice, recommendations, and subjective evaluations that are reflected in records pertaining to the decision-making process of or among agencies).

Distribution This document is intended for use by US Government agencies and their Contractors doing business with the U.S. Army Network Enterprise Technology Command. This document is for information purposes only and is not to be construed as directive in nature or official policy.

This document is available by request from NETCOM, ATTN: NETC-OP, 2133 Cushing Street, Fort Huachuca, AZ 85613-7070 daniel.octaviano Typewritten Text daniel.octaviano Typewritten Text Attachment J.2

NETC-OP-R-GEF-14-199-v1.2 ii

THIS PAGE IS INTENTIONALLY BLANK

iii

FOR OFFICIAL USE ONLY

DISCLAIMER

The contents of this document are not to be construed as an official Department of the Army position unless so designated by other authorized documents. The use of trade names in this document does not constitute an official endorsement or approval of the use of such commercial hardware or software. Do not cite this document for the purpose of advertisement.

CHANGES

Refer requests for all changes that affect this document to:

NETCOM

ATTN: NETC-OP

Fort Huachuca, AZ 85613-7070

DISPOSITION INSTRUCTIONS

Destroy this document when no longer needed. Do not return it to the organization.

Safeguard and destroy this document with consideration given to its classification or distribution statement requirements.

iv

FOR OFFICIAL USE ONLY

DOCUMENT REVISION LIST

DATE DESCRIPTION OF CHANGES ORGANIZATION

08 Aug 14 Initial NETCOM, G35

23 Apr 15 Quality Review of Version 1.2 NETCOM, G35

22 Jul 15 Revision from 5th RCC Feed Back NETCOM, G35

26 Aug 15 Revisions based on Mr. Bradford Feed Back NETCOM, G35

9 Mar 16 Revisions based on CG Feed Back NETCOM, G35

29 Mar 16 Revision based on Mr. Bradford Feed Back NETCOM, G35 v

TABLE OF CONTENTS

1 Purpose

2 References

3 Scope

4 Background

4.1 US Army Network and Directories Evolution

4.2 NETCOM’s GEF

5 Envisioning the US Army GEF

5.1 Converged Architecture Objectives

5.1.1 Converged Architecture Goals

5.1.2 US Army GEF Program Benefits

5.1.3 US Army GEF Overview

6 Operational Requirements

6.1 Resource Pooling

6.2 Elasticity and Perception of Infinite Capacity

6.3 Perception of Continuous Availability

6.4 Predictability

6.5 Service Planner’s Approach to IT

6.6 Multi-Tenancy

6.7 Security and Identity

7 Enterprise System Hardware Defined Requirements

8 Site-Level Hardware Defined Requirements

9 Site-Level Backup Software for Virtual Infrastructure Defined Requirements ... 13

10 Enterprise System Hypervisor Defined Requirements

11 Enterprise System Management Defined Requirements

12 Vendor Enterprise System’s Support Defined Requirements

13 Generalized Functional Requirements

13.1 Automation Layer

13.2 Management Layer

13.3 Orchestration Layer

13.4 Services Management Layer

13.5 Self-Service Layer

vi

FOR OFFICIAL USE ONLY

13.6 Security

14 Reference Model

15 Assessing Site Requirements for the Global Enterprise

15.1 Functional Requirements Matrix

15.1.1 Installation Size

15.1.2 Capability

16 Conclusion

Appendix A. Acronyms and Abbreviations

Appendix B. DFMN and RFN sites

Appendix C. IFN Sites

LIST OF FIGURES

Figure 1. LWN Transition Periods

Figure 2. Network visibility vision on the GEF

Figure 3. Minimum Hardware Specifications

Figure 4. A Typical Enterprise Level DFMN

LIST OF TABLES

Table 1: Domain Controller Consolidation

Table 2. Requirements - Enterprise Hardware, Compute

Table 3. Requirements - Enterprise Hardware, Networking

Table 4. Requirements - Enterprise Hardware, Storage

Table 5. Requirements - Site Hardware, File to Object-Object Gateway

Table 6. Requirements - Site Hardware, Backup to Disk

Table 7. Requirements - Hypervisor

Table 8. Requirements - Enterprise Manager System

Table 9. Requirements - Vendor's Systems Support

Table 10. Installation Size by AD Catalog vii

FOR OFFICIAL USE ONLY

EXECUTIVE SUMMARY

This document sets forth the functional requirements for the Global Enterprise Fabric. It includes a background and a brief history of the concepts of “cloud computing” and the evolution of the LandWarNet (LWN) enterprise.

The Global Enterprise Fabric is the Network Enterprise Technology Command (NETCOM) description for a cloud enterprise hosting environment that is envisioned to provide the US Army a complete suite of computing enterprise services under three broad areas: Infrastructure as a Service, Network Services, and Computer Network Defense. NETCOM will implement these requirements to meet the Department of Defense goals of a secure network and a responsive enterprise as envisioned by the Joint Information Environment (JIE).

FOR OFFICIAL USE ONLY

1 Purpose

This document sets forth the framework, terminology, and vision for the Global Enterprise Fabric (GEF) in addition to its requirements.

2 References

a. DoD CIO Memorandum, “Joint Information Environment Implementation Guide,” 26 Sep 13.

b. Joint Staff J3, “DOD Joint Information Environment (JIE) EXORD,” 05 Dec 12.

c. DoD CIO Memorandum, “Department of Defense Cloud Computing Strategy,” July 12.

d. US Department of Commerce, “The NIST Definition of Cloud Computing,” Sept 11.

e. AR 25-2, Information Assurance, 24 Oct 07 (Rapid Action Revision, 23 Mar 09).

3 Scope

The scope of the requirements laid out in this document applies to the Non-secure Internet Protocol Router Network (NIPRNet), Secret Internet Protocol Router Network (SIPRNet) and Global Mission Network (GMN) environments for all US Army units and organizations, including Army National Guard and Army Reserves. The GMN is a separate network that the Army built to extend strategic SIPRNET to the tactical formations. The intent is to merge the GMN infrastructure into the GEF using the same technical concepts of cloud, virtualization and hosted services.

4 Background

Information technology (IT), data, computer and enterprise networks across the Department of Defense (DoD) have been steadily shifting towards a cloud computing architecture, and today, the term cloud computing is more synonymous with the term “virtualization.”

Each year, the armed forces are investing in a scalable computing services concept that is independent of hardware changes made to their underlying infrastructure. This concept is notionally called a “converged hardware architecture.” The focus of this effort is to reduce IT costs, provide consistent and timely services to users, improve management of resources from a centralized design (i.e. a converged architecture), and establish responsive security measures uniform to the enterprise. With virtualization, physical resources such as servers, clients, data storage, and networking are conserved, while delivering the following attributes:

a. Elasticity and Scalability – Adding new resources and services is flexible and customizable to each organization’s mission need. Operations can better handle surging demands and peak usage through the tailoring of resources from computing power, virtual machines, storage, and bandwidth utilization.

FOR OFFICIAL USE ONLY

b. Pooled Resources – Computing, storage, and network resources are grouped in the same infrastructure environment to allow for reallocation of those resources by demand.

c. Customer Self-Service – Virtualization provisioning basic resources for a customer such as services, virtual machines, mailboxes, and user accounts without needing IT intervention.

d. Usage Monitoring and Auditing – Capturing metrics on resource consumption, reporting on installed services, and recording data for comparative baseline analysis will aid in the efficient management of the enterprise.

This trend continually evolves as the DoD seeks to leverage the armed services in adapting cloud computing strategies that will enable the department to achieve the goals of the Joint Information Environment (JIE).

4.1 US Army Network and Directories Evolution

Steady changes in commercial IT from 2000 to 2010 have had a direct impact on the DoD and affected the US Army’s IT infrastructure. The key technology enabling IT infrastructure and networks during this time was Microsoft Active Directory (AD) built around Windows New Technology (NT) 4.0 2004 platforms. This time is considered the “Pre-Enterprise Directory Services” period, wherein the US Army IT network consisted of multiple complex environments of stand-alone hardware in noncontiguous enclaves.

The decentralized aspect of the network in this earlier period added to the non-standardized “silo” effect of regionally developed AD solutions. Later, as a result of this decentralization, the US Army would have difficulty efficiently managing its network as an IT enterprise.

Starting in 2010, NETCOM has made great strides to bring the LWN enterprise to what it is today, a “Multiple Directory Services Environment.” Gone are the many noncontiguous network enclaves as a result of implementing an AD domain forest collapse throughout the enterprise. In its place are the contiguous multiple domain forests that will shape the LWN into an even more consolidated environment. However, today’s environment still has challenges regarding compliance and security, infrastructure complexity, and “server sprawl.” Table 1 gives a snapshot of users in the enterprise and the projected numbers of current domain controllers (DC) from the continued consolidation of the LWN enterprise based on the current method of deploying servers.

Table 1: Domain Controller Consolidation

Enclave Users Relevant

Users Current

DCs Current Funding

FY15

Proj DCs

FY15

Proj

Funding

Proj DC Reduction

%DC

Reduction

NIPRNet 1.4M 670K 458 $7M 320 $4M 138 43%

SIPRNet 140K 101K 255 $4M 166 $2M 89 53%

Total 1.54M 771K 713 $11M 486 $6M 227 -

4.2 NETCOM’s GEF

The GEF is NETCOM’s concept to meet the US Army’s goal of fulfilling the DoD JIE vision. However, meeting that goal requires transformative steps that mediate the evolution of the LWN enterprise and, in a deliberate manner, balance the needs of the US Army with JIE.

NETCOM envisions a “Theater Forest Single Domain Model” with five theater and functional domains: US Army Pacific (USARPAC), US Army Europe (USAREUR), South West Asia (SWA), Korea, and Continental United States (CONUS). The GEF, under this model, will establish “Enterprise Directory Services” on the Windows 2012 platform.

It will be 100% virtualized, centralized, and standardized with JIE, Joint Regional Security Stack (JRSS), JIE Management Network (JMN) Multi-Protocol Label Switching (MPLS) networks, and security stack architecture. Figure 1 below depicts the periods the LWN enterprise has undergone transition and consolidation.

Figure 1. LWN Transition Periods

5 Envisioning the US Army GEF

In addition to the continual consolidation of the Active Directory (forests and domains) directory services, NETCOM envisioned approach to the GEF hosting environment will take into account its computing enterprise services in three broad areas: (i) Infrastructure as a Service, (ii) Network Services, and (iii) Computer Network Defense.

Each computing enterprise service, having a broad area, is supported by specific services or “capabilities”. These services are evaluated in status and “rolls up” to give

FOR OFFICIAL USE ONLY

an overall status of the area in which they are organized. By establishing these three broad areas, NETCOM believes it will enable the ability to centrally manage and view the overall “health” status of its network.

Figure 2, below depicts how these services are organized in our current environment to present a “Network Health Hierarchy”.

Figure 2. Network visibility vision on the GEF

NETCOM envisions that the GEF will allow for centralized management and monitoring as the LWN enterprise matures into a cloud computing environment.

5.1 Converged Architecture Objectives

The Enterprise Fabric features a convergence of the US Army architecture in three broad areas:

a. Hardware converged architecture, where computing and network hardware are integrated, shared resources for the hosted infrastructure services (shown in Fig 2);

b. Virtual converged architecture, where virtual machines (VM) host each infrastructure service stored in a Storage Area Network (SAN)’s array;

c. Army converged services, where enterprise management systems are used for maintaining the environment.

This approach is to package hardware architecture in three configurable sizes for the GEF: small (IFN), medium (RFN or IFN), and large (DFMN), which are intended for deployment across US Army posts, camps, and stations within the enterprise. The GEF will consolidate the architecture at each site with the following objectives in mind.

a. Build Operate, Maintain, Defend, and “See the Core Operating Environment (COE) End-to-End”

FOR OFFICIAL USE ONLY

b. Global unfettered access to information

c. Global standard for Army networks, workstations, servers, applications, and data

d. Secure/reliable service, anywhere, anytime

e. Synchronization with JRSS solution

f. Centralized management, monitoring, and reporting

5.1.1 Converged Architecture Goals

Listed as follows are the envisioned engineering fabric pod goals:

a. Support for multiple diverse workloads

b. Full end-to-end high-availability

c. 100% virtualization

d. 100% automation

e. Self Service Portal for Administration and Guests

f. Sub-system scale-out for the following:

i. Compute

ii. Storage

iii. Networking

g. Reduction of cost to serve

h. Removal of middleware

i. Hardware platform independent

j. Just-in-time hardware provisioning

5.1.2 US Army GEF Program Benefits

Listed as follows are the envisioned benefits the GEF will offer:

a. Faster Deployment

i. End-to-end architectural and deployment guidance

ii. Streamlined infrastructure planning due to predefined capacity

iii. Enhanced functionality and automation through deep knowledge of infrastructure

iv. Integrated management for VM and infrastructure deployment

b. Reduced Risk

i. Tested end-to-end interoperability for computing, storage, and networking

ii. Predefined, out-of-box solutions based on a common cloud architecture

iii. High degree of service availability through automated load balancing

c. Lower Cost-of-Ownership

FOR OFFICIAL USE ONLY

i. Near-zero downtime with exceptional fault tolerance, providing high availability

ii. Dynamic Pooling that can enhance the use of virtualization resources by combining Hypervisor and supported storage and network devices

iii. Use of low-cost switches that consume less power and deliver high throughput for large bandwidth requirements

5.1.3 US Army GEF Overview

The GEF is conceived primarily as a hosting platform to virtualize the US Army NETOPS Enterprise capabilities and Directory Services at various US Army sites. The NETOPS Enterprise Capabilities currently used consists of Enterprise Directory Services (DS) and Authentication, Host-Based Security Systems (HBSS), ITSM/Remedy, Spectrum, Microsoft System Center, REM/Retina (Assured Compliance Assessment Solution) and Security Incident Management System (SIMS). These and other capabilities to include regional and local applications would be hosted as “workloads” or virtualized servers on a converged architecture.

A converged architecture refers to sharing a network topology between traditional network traffic and storage traffic. This means Ethernet network devices and network controllers must have converged features that will provide the segregation, quality of service (performance), and scalability for the fabric pod. The goal is for the GEF to be physically less complex, possess greater agility, and have lower costs than those solutions associated with traditional Fiber Channel-based storage networks.

NETCOM envisions that the topology needed must support the many storage systems used in converged architecture, including hyperconverged designs with traditional SANs and Server Message Block (SMB) 3.0-enabled SANs in order to integrate within the environment. The main points in a converged architecture are that all storage connectivity is network-based (iSCSI, FCoE for converged designs and network file system (NFS) or common Internet file system (CIFS) for hyperconverged designs), and it uses a single media type for traffic (such as copper. NOTE: Small Form-Factor Pluggable (SFP)+ adapters are more commonly used.

NETCOM envisions that the key difference between the fabric pod and traditional converged systems will be how the servers (shared computing) connect to the storage, and the advanced networking features provided by converged network adapters (CNA).

High-density server blade systems must feature advanced hardware options that present physical or virtual network adapters to the virtual host, while supporting a variety of protocols. Figure 3 depicts NETCOM’s analysis of the requirements expressed as a minimum hardware specifications (see Paragraph 7, Hardware Requirements, for a more detailed specification). Alternative solutions, configurations and specifications from industry will be considered.

Figure 3. NETCOM’s Analysis for Minimum Hardware Specifications

*NOTE: Alternative solutions, configurations and specifications from industry will be considered.

6 Operational Requirements

These principles, defined below, help power the GEF elasticity and also distinguish it from a traditional local area network (LAN) in which key pieces are virtualized. While virtualized LAN deliver some of the benefits of virtualization, such as increased utilization, an enterprise fabric model includes automation and management capabilities that can mean revolutionary changes in how the Army delivers enterprise IT services and how users consume them.

6.1 Resource Pooling

The GEF depends on the flexible pooling of computing (processor and memory), storage, networking, and software resources. This pooling helps deliver greater utilization and efficiency and is powered by virtualization, which abstracts the platform from the physical infrastructure. Multiple consumers—such as multiple customers or multiple organizational units—can share pooled resources, resulting in higher resource utilization and efficiency for both planners and users.

FOR OFFICIAL USE ONLY

6.2 Elasticity and Perception of Infinite Capacity

From the user’s perspective, GEF services should appear to have infinite capacity. End users can consume as much or as little of the service as needed, just as they consume electricity. This perception is possible because, in contrast to a reactive approach that leads to inefficient resource use, the private cloud facilitates proactive capacity planning so that the infrastructure can satisfy peak requests on demand. This principle helps achieve greater balance between the cost of unused capacity and the desire for agility.

6.3 Perception of Continuous Availability

From the user’s perspective, GEF services should always be available when needed.

The consumer should never experience an interruption in IT services, even if failures occur within the cloud infrastructure. To achieve this continuous availability, the private cloud architecture delivers a highly automated environment in which infrastructure redundancies, such as failover clustering, are complemented by intelligent automation and management capabilities.

6.4 Predictability

Both Regional Cyber Centers (RCCs) and users require predictability from a private cloud infrastructure. For consumers, GEF services should be consistent—they should have the same quality and functionality each time they are used.

To achieve this predictability, the virtualized environment standardizes functions across physical servers, network devices, and storage. This standardization helps to assure consistent treatment of hosted workloads, even during fluctuating demand. With virtualization, users can also benefit from predictability on the service Planner’s side of the console through its management and automation tools, which standardize service offerings and processes. This predictability is a fundamental requirement if planners are to deliver on the potential of a virtualized environment.

6.5 Service Planner’s Approach to IT

Historically, when units needed new or expanded IT services, they purchased the necessary components and then built an infrastructure specific to the service requirements. The result was often disappointing in terms of agility and also meant delays, duplicate infrastructure, increased costs, and poor utilization.

With virtualization units can instead make use of IT as a set of services they consume rather than as a collection of hardware they deploy. The virtualized environment helps planners provide infrastructure as a service (IaaS) so that users can consume what they need when they need it, avoiding an underutilized, duplicating infrastructure. In addition, the shared resource model means planners can take advantage of economies of scale and greater agility in providing additional services or expanding existing ones.

6.6 Multi-Tenancy

The GEF can be subdivided for each mission partner and provision logically isolated resources to different customers. Users can also benefit from the multitenant capabilities of the GEF infrastructure because resources can be provisioned for distinct organizational units within the Army LWN, which facilitates usage metering and chargeback.

FOR OFFICIAL USE ONLY

6.7 Security and Identity

The private cloud delivers strong security for cloud computing through three pillars:

a. Protected infrastructure

b. Application access

c. Network access

The GEF uses security and identity technologies to protect both physical and virtual hosts, information, and applications in the data center. These technologies take advantage of the least-privileged user account access principle—an approach that ensures that users always log on with limited user accounts until they are granted additional privileges.

The GEF will secure application access through integration with the DoD’s and Army Identity and Access Management (IdAM) system. IdAM is an enterprise capability that would be hosted as a workload on the fabric. This identity foundation ensures that users have secure access to IT resources within the enterprise by using numerous devices.

Network access in the private cloud is secured at the perimeter through the JRSS and through Host-Based Security System (HBSS, a DoD mandated capability). Internet Protocol Security (IPsec) also enables logical isolation of server and domain resources so that administrators can limit access to authenticated and authorized computers.

Alternative solutions will be considered if proposed.

7 Enterprise System Hardware Defined Requirements

Based on the Army’s analysis, the fabric pod, such as the DFMN is envisioned to have at least the following hardware requirements for computing, network access, and storage, and are presented in the following tables (Tables 2-4) as a proposed hardware specification, based on the government’s assessment of current technologies.

Alternative solutions, configurations and specifications from industry will be considered.

All hardware and software components must be on the DOD DISA Approved Products List (APL).

Table 2. Requirements - Enterprise Hardware, Compute

Compute Requirements

7.2.1. Configured with at minimum a primary and redundant compute centers with “n” number of machines for hosting virtualization

7.2.2. Configured to with at least 500 cores

7.2.3. Equipped with 10 TB host RAM minimum

7.2.4. Will have the minimum number of servers per cluster, which is four for optimal load balancing and availability

7.2.5. Will have at least two 10GbE ports per server.

7.2.6. Must fully support Out-Of-Band Management (OOBM, also referred to as “Lights-Out Management”) enabling full KVM access to the server.

FOR OFFICIAL USE ONLY

Compute Requirements

7.2.7. Server must support booting from internal SD Card or internal USB drive.

Table 3. Requirements - Enterprise Hardware, Networking

Network Requirements

7.3.1. Must be capable of Link Aggregation such as link aggregation control protocol (LACP).

7.3.2. Must have local-to-host virtualized storage controllers for supporting IP Storage.

7.3.3. Must have ability to tag/allow multiple VLANs on individual Ethernet ports or aggregate links.

7.3.4. Must be able to support fully redundant 10GB Ethernet ports.

7.3.5. Switch must be not more than 2U and support 1GbE and 10GbE and 8/16Gb native Fibre Channel on all slots.

7.3.6. Minimum of 32 fixed ports.

7.3.7. Must support Layer 2 and Layer 3 traffic on all ports.

7.3.8. All physical network devices must be able to be monitored by US Army network monitoring tools.

7.3.9. Any network element must use two or more authentication servers for the purpose of granting administrative access.

7.3.10. Have at least separate switch infrastructure to support out-of-band management supporting 100Mb Ports.

Table 4. Requirements - Enterprise Hardware, Storage

Storage Requirements

7.4.1. Automated tiering across all disk storage pools or disk provisioning groups.

7.4.3. Ability to dynamically allocate Flash Drive capacity to Storage Processor read and write cache for increased performance and serve the entire array, or selectively choose which pools to support.

7.4.4. Must support Solid State Hard Drives.

7.4.5. Must support multi-drive, multi-protection level, and performance tiering within a storage pool.

7.4.6. Must have storage processors able to support of Multi Core CPU Processing.

7.4.8. SLA 4 Hour acknowledgement time in the event of technical issues with a 24 hour resolution time.

7.4.9. System must have 99.999% availability/uptime

7.4.10. Storage tiering among multi-tiered, in-memory caches, SSD and HD.

7.4.11. Must support Disk Storage Pools or Disk Provisioning Groups.

7.4.13. Storage Pools or Provisioning Groups must support Solid State Disks as well as all speeds of traditional mechanical disks.

7.4.14. Must be able to mix drive types within the same disk shelf.

7.4.16. Must provide user selectable data protection levels

7.4.17. Must be able to support a minimum of 175,000 or more IOPS

7.4.18. Disks may not be used in more than one Disk Storage Pool or Disk Provisioning Group at a time.

FOR OFFICIAL USE ONLY

Storage Requirements

7.4.19. Must support 8/16GB Fibre Channel and/or 10GbE Network connectivity.

7.4.20. Must support block level storage.

7.4.21. Must support LUN snapshots or more granular, per-VM snapshots.

7.4.22. Must support the use flash memory for system I/O caching.

7.4.24. Must do block or variable length deduplication.

7.4.25. Must do block or sub-block compression.

7.4.26. Must be able to present thin provisioned storage resources.

7.4.27. Proposed solution must not be end of life

7.4.29. Must have scalable storage for growth capacity.

7.4.30. Must employ or support existing data-at-rest encryption solutions currently used by the US Army.

8 Site-Level Hardware Defined Requirements

The following are requirements for the installation fabric node (IFN), typically at the site garrison level based on the government’s assessment of current technologies. The IFN is characteristically the Army Network Enterprise Center (NEC) and is a “service” node as it sends data to the management node. Alternative solutions, configurations and specifications from industry will be considered.

Table 5. Requirements - Site Hardware, File to Object-Object Gateway

Data Ingester Requirements

8.5.1. Solution supports file sharing over global namespace and global locking and NAS integration with object store.

8.5.2. Data at Rest Encryption - Data stored in all of the components of the solution is encrypted at rest.

8.5.3. Data in Flight Encryption - Communications between all of the components of the system are encrypted.

8.5.4. Full support for standard NAS features, such as AD (including Windows 2012 AD), LDAP, CIFS, NFS, and S3.

8.5.5. Supports Content Sharing/Roaming Home Directories - Users can easily access content from any site.

8.5.6. Supports a Global Access Topology and namespace, with multi-layer caching (on the endpoint, in site caches, and in content distribution caches) and selective pre population capabilities allowing users and applications to access data from the device nearest in proximity for improved collaboration, continuity, performance and streamlined availability processes.

8.5.7. Supports Adaptive Cloud Tiering - adapts to changes in file metadata, then automatically tiers corresponding content to the appropriate private or public cloud storage tier for enhancing TCO and security.

8.5.8. Multi-cloud support within same namespace, so to host different data sets in different cloud tiers;

such as S3 enabled services.

FOR OFFICIAL USE ONLY

Data Ingester Requirements

8.5.9. Supports replication, data protection and file restore without requiring additional HW or SW.

Supports file system point in time snapshots for recovery of file and folders by both the administrator and the end users.

8.5.10. Compatible granular archive policies that provide the capability to tier storage from local devices to consolidated storage, to archive storage for long…