Atch 2 DREN4-PWS-Rev 2-Amend 0002-20200224.pdf

Section C

PERFORMANCE WORK STATEMENT (PWS)

As of 24 Feb 2020

Contract Number

Task Order Number Not Applicable

Contractor Name

Tracking Number

Follow-on to Previous Contract and Task Order Number Not Applicable i

Table of Contents

1. Contracting Officer representative (COR)

2. Contract Title

3. Background

3.1. DREN Evolution

3.2. DREN Technical Leadership

4. Objectives

5. Scope

5.1. DREN4 Program Objectives

5.2. Continuation of DREN Services

5.3. Service Locations and Duty Hours

5.4. Synopsis of Future Network

6. Performance Requirements

6.0. Base Requirements for All Tasks

6.0.1. Hardware and Software

6.0.2. General Guidance

6.1. DREN Transport

6.1.0. Elements of Base Task

6.1.0.1. Collectives

6.1.0.2. Performance

6.1.0.3. Buffering

6.1.1. Ethernet

6.1.1.1. Switching

6.1.1.2. Multicast

6.1.1.3. Ethernet Quality of Service (QOS)

6.1.1.4. VLAN

6.1.1.5. Encryption

6.1.1.6. Frame Size

6.1.1.7. Ethernet Resiliency

6.1.2. Internet Protocol (IP) Transport

6.1.2.1. IPv6

6.1.2.2. IPv4

6.1.2.3. IP Maximum Transmission Unit (MTU)

6.1.2.4. Unicast

6.1.2.5. Multicast

6.1.2.6. Anycast

6.1.2.7. IP Quality of Service (QoS)

6.1.2.8. Multiple IP networks

6.1.2.8.1. Public External (PX) IP Network

6.1.2.8.2. DoD Only (DO) IP Network

6.1.2.8.3. Non-DoD Access (ND) Network

ii

6.1.2.8.4. Extended DMZ (ED) Network

6.1.2.8.5. Management Networks

6.1.2.9. IP Routing

6.1.2.9.1. Best Current Practices

6.1.2.9.2. Routing Protocols

6.1.2.9.3. Peering

6.1.2.9.4. Architecture

6.1.2.9.5. Security Gateways (SGs)

6.1.2.9.6. Route Filtering

6.1.2.10. Controls, Policies, and Filtering

6.1.2.11. Internet Transit Service (ITS) (Separately Orderable)

6.1.2.11.1. Full Internet Transit

6.1.2.11.2. Outreach

6.1.2.11.2.1. Outreach Peering and Routing 21

6.1.2.11.2.2. Outreach Transport 21

6.1.3. Transport Performance

6.1.3.1. Latency

6.1.3.2. Jitter

6.1.3.3. Loss

6.1.3.4. Throughput

6.1.3.5. DCN Placement

6.1.3.6. Measurement and Testing

6.1.3.6.1. Latency Test

6.1.3.6.2. Pairwise TCP Test

6.1.3.6.3. Aggregate TCP Test

6.1.3.6.4. Pairwise Throughput Test

6.1.3.6.5. Aggregate Throughput Test

6.1.3.7. Degradation/Outage

6.2. DREN Node

6.2.0. Elements of Base Task

6.2.0.1. Government Data and Access Requirements

6.2.0.1.1. Flow

6.2.0.1.2. Log

6.2.0.1.3. Simple Network Management Protocol (SNMP)

6.2.0.1.4. BGP

6.2.0.1.5. Government Access to Network Components

6.2.0.2. DREN Node Types

6.2.0.2.1. Service Delivery Point (SDP)

6.2.0.2.2. DREN Core Node (DCN)

6.2.0.2.3. DREN eXchange Point (DXP)

6.2.0.3. DREN Node Line Rate

6.2.0.4. Physical Security at DCN and DXP Locations

6.2.1. Switch Function (One included)

iii

6.2.1.1. Ports (Separately Orderable)

6.2.1.2. Modules (Separately Orderable)

6.2.1.3. Interconnections

6.2.1.4. Additional Switch Functions (Separately Orderable)

6.2.2. Router Function (Separately Orderable)

6.2.3. Firewall Function (Separately Orderable)

6.2.4. Compute Function (Separately Orderable)

6.2.4.1. Generic Compute Function

6.2.4.2. DAMP Compute Function

6.2.4.3. DJS Compute Function

6.2.5. Orchestration

6.2.5.1. Orchestrator

6.2.6. Internet Peering and Transit

6.2.6.1. Private Peering

6.2.6.2. Colocation and Cross-Connects at DXP locations

6.2.6.2.1. Colocation

6.2.6.2.2. Cross-Connects

6.2.7. Rack Space (separately orderable)

6.2.8. Passive Tap (separately orderable)

6.2.9. SDP Lite (SDP-L)

6.2.10. Tunnel Termination Point (TTP) (Separately Orderable)

6.3. Security

6.3.1. RMF Support

6.3.1.1. RMF IATT Package

6.3.1.2. RMF ATO Package

6.3.1.2.1. Systems Security Plan

6.3.1.3. Continuous Monitoring

6.3.2. Configuration Control Board Change Requests

6.3.3. Network Protections

6.3.4. Initial Boundary Protection Deployment

6.3.5. INFOCON/CPCON Changes

6.3.6. Intrusion Detection Systems (IDSs)

6.3.7. Network Management

6.3.8. Secret Defense Research and Engineering Network (SDREN)

6.4. Management

6.4.1. Management Oversight

6.4.1.1. Program Management

6.4.1.2. Program Management Office

6.4.1.3. Project Management Planning and Control

6.4.1.4. Other Direct Cost (ODC) Management

6.4.1.5. Progress Reporting

6.4.1.6. DREN Meetings

6.4.1.6.1. Technical Interchange Meeting (TIM)

iv

6.4.1.6.2. Contract Status Meetings

6.4.1.6.3. Technical Advisory Panel (TAP)

6.4.1.7. Asset and Configuration Management

6.4.1.8. Program Management Review (PMR)

6.4.1.9. Annual Planning and Design Review

6.4.2. Network Status Reporting

6.4.3. Evolution of Services

6.4.3.1. Technology Insertion Proposal (TIP)

6.4.3.1.1. Commercial Solutions for Classified (CSfC)

6.4.3.1.2. Enhanced Cybersecurity Service (ECS)

6.4.3.1.3. Boundary Cloud Access Point(s)

6.4.3.1.4. Time Reference Service

6.4.3.1.5. Contractor provided localized commodity Internet service

6.4.3.1.6. Hybrid SDP

6.4.3.2. Upgrades

6.4.3.3. Technical Refresh and Life Cycle Engineering Support

6.4.4. Simulation and Test Labs (Requirements and Status)

6.4.5. Accounting Management

6.4.6. SCRM plan

6.4.7. SCRM Plan Update

6.4.8. Combating Trafficking in Persons

6.5. Support

6.5.1. Service Provisioning

6.5.2. Change Request Provisioning

6.5.3. Service Management System (SMS)

6.5.3.1. Tickets (other than "Service" type)

6.5.3.2. Tickets (Service)

6.5.4. Contractor Managed Network Database

6.5.5. Network Operations Center (NOC)

6.5.5.1. Notifications

6.5.5.1.1. Outage Notification Methods, Levels, and Intervals

6.5.5.1.2. Security Incident Notifications

6.5.5.1.3. Contractor-Initiated Maintenance Notifications

6.5.5.1.4. Subscriber-Initiated Maintenance Notifications

6.5.6. Problem Management

6.5.7. DREN Node and Network Availability

6.5.7.1. DREN Node Outages

6.5.7.1.1. DREN Node Outage Time

6.5.7.1.2. DREN Node MRC Billing Credits

6.5.7.2. Network Availability

6.5.7.2.1. Adjusted Network Availability (ANA)

6.5.7.2.2. ANA Total MRC Billing Credits

6.5.7.3. DREN Node and Network Availability Report

v

6.5.8. Problem Escalation

6.5.9. Data Access and Storage Requirements

6.5.9.1. DREN Network Dynamic Data

6.5.9.1.1. API

6.5.9.1.2. Looking Glass

6.5.9.1.3. Data Dashboard

6.5.9.1.4. Flow Tool

6.5.9.2. Government Documentation Repository

6.5.10. OOB Access

6.5.11. Regression Testing

6.5.12. DREN Node Documentation

6.5.12.1. DREN Node Master Plan

6.5.12.2. Individual DREN Node As-Built Reports

6.5.12.3. DREN Node Site Survey Template

6.5.12.4. DREN Node Site Surveys

6.5.12.5. DREN Node Location Modification Plan

6.5.13. Acceptance Testing

6.5.13.1. Acceptance Test Plan

6.5.13.2. Acceptance Test Report

6.5.13.3. Acceptance Procedures

6.5.13.4. Tools and Test, Measurement, and Diagnostics Equipment (TMDE)

6.5.14. DNS Service

6.5.15. Touch Labor

6.6. Implementation and Transition

6.6.1. Phase I

6.6.1.1. Initial Performance Capability (IPC)

6.6.1.1.1. IPC Plan

6.6.1.1.2. Requirements Traceability Matrix (RTM)

6.6.1.1.3. IPC Implementation

6.6.1.1.4. IPC Demonstration Plan (IPCDP)

6.6.1.1.5. IPC Test and Demonstration

6.6.1.1.6. IPC Demonstration Report (IPCDR)

6.6.1.2. Assess and Authorization Process

6.6.1.3. Comprehensive Implementation and Transition Plan (CITP) Development

6.6.2. Phase II

6.6.2.1. CITP Execution

6.6.2.2. Subscriber Cutover

6.6.3. Contract Phase Out

6.6.3.1. Planning and Engineering Support

6.6.3.1.1. Development of Contract Phase-out Transition Plan

6.6.3.1.2. Updating, Validating, and Transferring of Support Documentation

6.6.4. Network Phase Out

7. Performance Standards vi

8. Incentives

9. Place of Performance

10. Period of Performance

11. Deliverables

12. Security

12.1. Personnel Security

12.2. Email

12.3. Visits

12.4. Training and Certification

12.5. Common Access Card (CAC)

12.6. Physical Security

12.7. Facility Clearance

12.8. Protection of Sensitive and Classified Data

12.9. Media Sanitization and Disposal

12.9.1. Unclassified Media Sanitization

12.9.2. Classified Media Sanitization

13. Government-Furnished Equipment (GFE)/Government-Furnished Information (GFI)

14. Other Pertinent Information or Special Considerations

14.1. Identification of Possible Follow-on Work

14.2. Identification of Potential Conflicts of Interest

14.3. Supply Chain Risk Management (SCRM)

15. Section 508 Accessibility Standards

15.1. Technical Standards

15.2. Functional Performance Criteria

15.3. Information, Documentation and Support

Appendix A. Acronyms

1. CONTRACTING OFFICER REPRESENTATIVE (COR)

a) Primary COR.

Name

Organization

Department of Defense Activity Address Code

(DODAAC)

Address

Phone Number

Fax Number

E-Mail Address

b) Alternate COR.

Name

Organization

DODAAC

Address

Phone Number

Fax Number

E-Mail Address

2. CONTRACT TITLE

Defense Research and Engineering Network 4 (DREN4) Contract.

3. BACKGROUND

The High Performance Computing Modernization Program (HPCMP), established in response to Congressional direction in 1992 to modernize Department of Defense (DoD) high performance computing (supercomputing) capabilities, is chartered to establish, provide, and maintain leading edge High Performance Computing (HPC) capability for scientists and engineers engaged in DoD RDT&E missions. Additional background material on the HPCMP is at https://www.hpc.mil.

The Defense Research and Engineering Network (DREN), a component of the HPCMP, provides secure high performance wide area network services in support of DoD scientists and engineers, as well as other related

DoD communities and Federal agencies. All of these groups and organizations when connected to the DREN

Network are the “DREN Subscribers”, a term used throughout this PWS. The networks they attach to DREN are referred to as the “Subscriber Enclave”.

3.1. DREN Evolution

DREN4 is the fifth generation of DREN. The first generation was Government owned and operated. All subsequent DREN generations have been accomplished under Indefinite Delivery/Indefinite Quantity (ID/IQ) network services contracts. The history of DREN is depicted in Figure 3.1, showing how the network services, bandwidths, and implementations have evolved over time to keep up with new technologies and increasing bandwidths.

Figure 3.1 DREN History

DREN 0 “IDREN” (1995-1997)

Government-owned

T1s and T3s

Cisco routers

Native Internet Protocol (IP)

Asynchronous Transfer Mode (ATM) test bed

Defense Information Systems Agency (DISA)-supported Network Operations Center (NOC)

DREN 1 “DISC” (1997-2002)

AT&T ID/IQ contract (5-year)

Cisco (IP), Fore (ATM)

OC-12 (13 x DREN 0)

ATM (native)

IP over ATM

IPv6 test bed over ATM

Contractor-provided NOC

DREN 2 “DREN II” (2002-2012)

Verizon ID/IQ contract (10-year)

Juniper routers

IPv4 and ATM over Multi-Protocol Label

Switching (MPLS)

10 Gigabits (16 x DREN 1)

IPv6 "when commercially available"

IP Security (IPsec) and VPLS [Virtual Private

LAN Service] (Ethernet) added

Lightwave services

Contractor-provided NOC

DREN 3 “DREN III” (2012-2022)

CenturyLink ID/IQ contract (10-year)

Alcatel-Lucent-Nokia routers

100 Gigabits (10 x DREN 2)

IPv6 with support for legacy IPv4

Ethernet and IP Services, No ATM

Optical Services (Optical Wavelength Service, Optical Transport Network, Alien Waves)

Contractor-provided NOC

The current DREN networking service is provided by a private virtual Wide Area Network (WAN) built on a commercial communications network and provides transport services between defined sites that comprise

DREN. Sites are currently specified in terms of bandwidth requirements, physical interfaces, and transport protocols.

DREN is a high performance communications network that incorporates the best capabilities of both DoD and the commercial infrastructure. DREN includes connectivity to other Research and Education (R&E) networks via private and public peering. Currently DREN comprises more than 180 sites ranging in bandwidths from 50

Megabits per second (Mbps) through 40 Gigabits per second (Gbps). DREN changes continually with the addition of new sites, changing bandwidths at existing sites, removal of existing sites, and insertion of new technology into the network.

3.2. DREN Technical Leadership

Through the many generations of DREN, DREN has been a leader in the implementation and use of advanced high performance networking technologies. For example, the DREN community was among the early users of the Advanced Research Projects Agency Network (ARPANET) and has been a leader in emerging technologies such as IPv6.

DREN4 is a significant shift from DREN III, with most of the intelligence of the network moving from the network edge to the network core. This will have multiple benefits, including:

a) network routing and other processing is done in the core at provider’s locations, allowing for fewer aggregated resources and less equipment at difficult to access Government sites

b) the edge no longer requires expensive routers

c) ability to implement hop-by-hop encryption that readily aligns with the core architecture

4. OBJECTIVES

The objective of this contract is to provide state-of-the-art WAN transport and related services to support the

DREN community. DREN's primary mission is to support the DoD HPC, Research and Development (R&D), Science and Technology (S&T), Test and Evaluation (T&E), Modeling and Simulation (M&S), and Acquisition

Engineering (AE) communities. DREN also provides network services to other select Federal Agencies and academia. The network links the DREN community together, to supercomputing resources, and to Federal, academic and Cloud Service Provider (CSP) networks, as well as the Internet.

All activities on this contract shall comply with all standards and guidance as prescribed in the awarded contract and references therein.

It is anticipated that DREN4 will be implemented as follows:

a) upon contract award, begin Initial Performance Capability (IPC)

b) no later than 12 months after contract award, begin execution of Comprehensive Implementation and Transition Plan (CITP)

c) no later than 24 months after contract award, complete execution of the CITP

5. SCOPE

DREN is a services contract providing high performance network and related services to the DREN

Communities (as outlined above) anywhere, anytime.

5.1. DREN4 Program Objectives

Transport and service requirements for DREN4 are derived from Subscriber requirements for synthesized network environments and the need to engage in collaborative initiatives. Many DREN Subscribers employ applications that require enormous computing capabilities. The corresponding network traffic to support these HPC and distributed collaborative environment capabilities is projected to require constant increases in bandwidth throughout the life of the contract.

Therefore, DREN4 services will support the following:

a) collaboration and effective pooling of resources

b) real-time scientific visualization

c) rapid access to multi-media libraries and large distributed computational resources using meta-computing approaches

d) access for DREN sites to the Internet, national research and education networks, national and regional optical networks, and various R&D network test beds

e) connectivity between DoD Shared Resource Centers for large scale distributed computing, distributed mass storage file systems, and archival storage

f) very large single stream data rates between user desktops and large scale computational systems, databases, libraries as well as other systems

g) connectivity to CSPs

h) special dedicated connectivity between members of a Community of Interest (COI)

i) shorter term dedicated (virtual) connectivity builds for special projects, exercises, and demonstrations

5.2. Continuation of DREN Services

Current DREN networking capability is provided under the DREN III Contract administered by Defense

Information Technology Contracting Organization (DITCO). This procurement will enable continuation of

DREN network services.

5.3. Service Locations and Duty Hours

The Contractor shall provide DREN services on a 24 hour a day, seven day a week all days of the year basis.

This will be referred to in this PWS as 24x7x365. Since every calendar day is a working day, no distinction is made in this PWS between them. All reference to days indicates calendar (which is also working days).

Locations supported under the current DREN contract as well as future anticipated sites are identified in the

Contract Line Item Number (CLIN) Tables. Service to any listed location may or may not be ordered under this solicitation. Additional locations may be added as fully negotiated modifications to the contract. Locations can be both within and outside CONUS [Continental United States].

5.4. Synopsis of Future Network

DREN4 represents a significant change in the requirements and characteristics of the services provided and where the services will be placed in the network. Figure 5.1 outlines the key features of DREN4.

Figure 5.1

DREN 4 “DREN4” (2022-2032)

ID/IQ contract (10-year)

Lightweight edge with intelligent core

Switching, routing, and computing functions

Software Defined Networking (SDN), Network

Function Virtualization(NFV), orchestration

400-Gigabits (4 x DREN 3)

IPv6 with support for legacy IPv4

Ethernet and IP Services

Hop-by-hop encryption (i.e., Media Access Control

Security (MACsec))

No optical services

Contractor-provided NOC

6. PERFORMANCE REQUIREMENTS

DREN4 will be a high-performance DoD WAN service, providing Layer-2 Ethernet and Layer-3 IP transport and associated services to DREN Subscribers, primarily at U.S. locations. This will incorporate most of the network characteristics of DREN III, but will evolve to include higher bandwidths, organic encryption, faster provisioning, increased resiliency, robust access to CSPs, better support for security infrastructure, added visibility and control in the core, and other features to address Subscribers needs and security threats. There will be a NOC responsible for overall network monitoring and control, along with a Help Desk and online support portal for Government and Subscriber interactions. The network will be accredited in accordance with Risk Management Framework (RMF) standards and policies.

Ethernet transport will include a wide area Ethernet service, offering private Virtual Local Area Networks

(VLANs) and trunks between DREN Subscribers upon request. IP transport will include full functionality for both IPv6 and legacy IPv4 protocols, with unicast, multicast, and anycast routing and addressing features. This will be instantiated as multiple independent IP networks, with some being pre-defined and others added during the life of DREN4. Router functions in the network will interconnect these networks as required using standard internal and external routing protocols and will provide peering to external networks and transit services to the full Internet. These IP and Ethernet networks will be grouped into "Collectives" (a DREN-unique term) based on governance, routing architecture, encryption, and other attributes. Interconnects between Collectives will include a Security Gateway (SG) function administered by the Government.

DREN is implemented as a private overlay network on existing commercial network infrastructure and services. In this document, the term "provider" will be used to refer to the owner or manager of the underlying network over which DREN is constructed and operated. The "provider backbone" is that portion of the underlying network used to implement DREN. This could also be referred to as the "provider core" or

"provider network".

Building DREN will require the provider to connect DREN Nodes to the provider backbone. This connection could be implemented using fiber, a wavelength, a circuit, or other technologies, or a combination of the above, along with any associated regeneration, multiplexing, switching, or routing. In this document, these connections will be referred to as an “access link”

It is assumed that the provider backbone is constructed of high speed data links interconnecting major junctions where switching, routing, and other functions exist. These junctions will be termed Network

Junction Points (NJPs). It is assumed that these NJPs are in provider owned and controlled facilities.

DREN4 will be comprised of physical nodes (i.e., "DREN Nodes") interconnected by provider backbone and access links. There will be three types of DREN Nodes, generally characterized by location and purpose, and named Service Delivery Point (SDP), DREN Core Node (DCN), and DREN eXchange Point (DXP).

SDPs are physically installed at Subscriber sites to deliver DREN services to the Subscribers at a given location.

DCNs are at provider facilities and are all interconnected via the provider backbone, forming a network

"intelligent core". They perform switch, router, and other network functions, instantiated either physically or virtually. They will be strategically placed to minimize latency between other DREN Nodes, and will be appropriately sized to meet aggregate demands.

DXPs are installed at Internet eXchange Points (IXPs) and other locations for public and private external peering.

SDPs and DXPs will be "homed" to DCNs. All DREN Nodes will communicate primarily via MACsec enabled

Ethernet paths at rates of 1G, 10G, 100G, or multiples thereof.

DREN Nodes will all include a switch function, to provide bridging of Ethernet segments, and to provide VLAN support. DREN Nodes will optionally include a router function, to provide routing between IP network segments, and to support routing protocols. These functions could be provided physically or virtually.

DREN4 performance requirements include a geographically based maximum latency between DREN Node pairs. There is also a requirement to support single-stream Transmission Control Protocol (TCP) at near line-rate, with some specific exceptions (e.g., 100G+ over large distances).

DREN4 Security requirements include the need for confidentiality and integrity using encryption over any shared infrastructure. Some DREN Subscribers will separately encrypt their data, but where this is not the case then portions (VLANs) of the access links must be encrypted. Between DCNs, certain VLANs must be encrypted across the provider backbone. MACsec is the encryption required for any of the Ethernet based connections.

A DREN SDP will be comprised of the minimum hardware necessary to meet Subscriber connection requirements, generally no more than a managed Ethernet switching function with support for MACsec encryption and enough interfaces to support the access link and all independent Subscribers at that site. IP router functions will not be needed at most SDPs, but will instead be performed at a DCN.

DXPs will require cross-connects within a facility to reach exchanges, national research and academic networks, and direct connections to CSPs.

DCNs will perform the bulk of DREN traffic processing, using physical appliances and/or virtual functions on a

NFV platform, tailored to meet performance requirements for all SDPs and DXPs homed to a given DCN. DCN functionality includes encryption/decryption of access and backbone Ethernet paths, Ethernet switching, IP routing (unicast, multicast, and anycast) for both IPv6 and legacy IPv4 using internal and external routing protocols as appropriate. DCNs may also include compute and storage infrastructure to support NFV where

DREN4 functions can be implemented virtually if of sufficient performance, and where unique government needs (e.g., virtual security appliances) may be implemented.

DREN4 will peer with many external networks, primarily at the DXPs, but to reach the rest of the Internet it may subscribe to Internet Transit Service (ITS) at two or more locations. The ITS locations will be at DCNs or

DXPs, optimally chosen based on the provider's topology.

It is envisioned that network components and functions will have mainstream Application Programming

Interfaces (APIs) that enable role-based access to programmable configuration, observation, and other SDN type functionality, which can then be orchestrated to support repeatable processes to facilitate automation and faster provisioning and improved visibility and control. Example uses are where DREN could provision

VLANs between multiple cooperating sites and optionally enable encryption, or opt-in to security controls in the core, or instantiate a service chain of security functions tailored to their enclave.

Where rapid provisioning is required (days instead of months), or where the Subscriber’s need is temporary, or otherwise unique, and where performance requirements can be relaxed, the Government includes the SDP

Lite (SDP-L) requirement. SDP Lite is a normal SDP except the access link is any connection of opportunity (3G, 4G, 5G, cable modem, Non-Classified IP Router Network (NIPRNet), etc.) that is available at the Subscriber site to securely tunnel traffic to a DCN, and where the site personnel perform the physical installation of the hardware and its connections. Transport performance requirements are relaxed for this situation.

6.0. Base Requirements for All Tasks

6.0.1. Hardware and Software

All of the hardware and software used in the network shall be compatible, fully interoperable, and completely support all of the features necessary to meet or exceed the requirements.

All hardware and software within the DREN4 Authorization Boundary shall be compliant with all relevant

Government guidance documents.

6.0.2. General Guidance

In all cases in the PWS where a feature, capability, or characteristic is stated as “shall…”, then the Contractor shall take all necessary steps to implement that requirement.

Although the typical use of the term Subscriber is used to describe other organizations and groups with connections to DREN Nodes, for the requirements here, the HPCMP and DREN Program are also Subscribers when connected to the network and using DREN services.

In the DREN4 Contract the HPCMP DREN program is the customer, however, any reference to Customer in this

PWS shall mean both the DREN program as well as the Subscribers to the network.

References to "the Government" in this PWS shall mean Government representative(s) as designated by the

DREN Program Manager through the Contracting Officer (KO).

An "interface" is defined as a switch port, which may or may not include a pluggable module. This common term is used whenever the distinction between a port and a module is unnecessary.

For Deliverables, Standard Distribution shall mean one copy of the transmittal letter with the deliverable to the Contracting Officer and to the COR(s); and the Deliverable submitted and made available to the

Government in the 6.5.9.2 Government Documentation Repository. All deliverable materials and documents under this PWS shall be the property of the Government. All materials and documents provided online shall be available for download and unrestricted use by the Government at no additional cost.

The Contractor shall convey to the Government all Deliverables on time, accurate, and error free.

All Government requested revisions or corrections shall be resubmitted within seven days to the KO/COR.

Failures to meet these requirements will result in a credit for the Government from the Contractor’s Monthly

Recurring Charge (MRC) for the NOC.

Task Performance

Standard

Acceptable Quality Level (AQL) Surveillance Method Incentives (+/-)

6.0.2 General

Guidance

Deliverable schedule and accuracy

Deliverables and all revisions and corrections to deliverables are on time, accurate, and error free.

Periodic Inspection:

Government review of

Deliverables for delivery time, accuracy, and errors.

-.5% of NOC MRC per incident of not meeting any of the delivery time, accuracy, and error requirements.

-.5% of NOC MRC for each additional 7 days past the delivery time requirement.

6.1. DREN Transport

DREN transport shall include the transport of layer 2 Ethernet frames and layer 3 IPv6 and legacy IPv4 packets between any DREN Nodes.

Ethernet and IP traffic transmitted between and through DREN Nodes shall be transported through the shortest path available that maintains the Transport Performance requirements, the security requirements, and other policy characteristics. The transport requirements also include establishing connectivity to external

DoD, Federal, private peers and the Internet.

6.1.0. Elements of Base Task

6.1.0.1. Collectives

DREN III introduced and defined the term Collective, a term that is unique to DREN and which is used to group networks at the macro level based on governance and routing architecture. Each of the many Layer-2 or

Layer-3 networks implemented on DREN will be a member of one (and only one) of these Collectives.

Collective membership is used to define how a given network must be implemented on DREN, how it connects to other networks, and how strongly it must be separated from other networks.

Governance is a primary attribute for defining Collectives. Governance acknowledges the established policies for how networks must be built, secured, accredited, and operated. Networks within a given Collective can interconnect with one another with minimal restrictions. Network interconnections between Collectives must traverse border controls that may be very restrictive.

Routing and switching architecture is another attribute of Collectives. The network and routing topology, External Gateway Protocol (EGP), Interior Gateway Protocol (IGP), and other factors will differ depending on the Collective.

There are currently three Collectives: DoD Collective, Internet Collective, and Affiliates Collective. The DoD

Collective includes all networks that carry intra-DoD traffic. The Internet Collective includes the networks that directly connect to the Internet through public and private peering. The Affiliates Collective includes networks supporting other (non-DoD) Federal Agencies.

The DoD Collective is governed primarily by DoD 8500.01 and related policies, and its member networks must be protected and accredited in accordance with DoD 8510.01. These networks connect directly to DREN

Subscribers and to other external DoD networks (e.g., NIPRNet). These networks require strong separation and protection from underlying commercial networks and from networks in other Collectives, generally through use of encryption technology. These networks must not cross a border to other Collectives, unless they do so via an approved SG. The routing architecture in the DoD Collective focuses on the optimization of intra-DoD traffic routing, and best exit through an SG.

The Internet Collective is governed through Best Current Practices (BCPs) (as defined by the Internet

Engineering Task Force (IETF), North America Network Operator’s Group (NANOG), and other associations), and through bilateral peering agreements with other Internet Service Providers (ISPs). Routing architecture in the Internet Collective focuses on internal and external metrics for optimizing traffic flows to and from the

Internet.

The Affiliates Collective is governed by the requirements of the Agencies that its member networks support.

They fall outside the scope of DoD governance, yet need protection from the open Internet. DREN will provide separation from other networks, but specific boundary protection infrastructure such as Managed

Trusted Internet Protocol Service (MTIPS) is outside the scope of DREN.

6.1.0.2. Performance

The ability to transfer data between DREN Nodes shall be possible at the DREN Node rate mutually available between the two DREN Nodes.

The Contractor shall engineer and install transport capacity sufficient to support all DREN Nodes simultaneously transmitting at the peak data rates specified by the Government. The Contractor shall expand transport capacity should subsequent modifications or additions to DREN Nodes on the network exceed the available transport capacity.

Each DREN Node's transport functions shall operate with sufficient independence such that:

the ability to provide concurrent transport between other DREN Nodes shall not have any reduction in performance any testing shall not reduce transport performance for all DREN Nodes not under test individual capabilities and functions can be added, modified, or eliminated without reducing the performance of other existing capabilities and functions

6.1.0.3. Buffering

Sufficient buffering shall be provided wherever switching and routing takes place to sustain high performance

TCP flows. This means that each transport device (physical or virtual) shall support the allocation of a

Bandwidth Delay Product (BDP) worth of buffering to a single flow. For example, an 80 ms Round Trip Time

(RTT) requires buffering of 10MB for 1G interfaces and 100MB for 10G interfaces.

6.1.1. Ethernet

The DREN4 network shall transport Ethernet frames between and through DREN Nodes. All delivered services

(e.g., IP) will be transported over this Ethernet layer. The network shall support switching, encryption, layers of 802.1Q tagging, and multicast.

6.1.1.1. Switching

The DREN4 network shall support bridging and switching functions. The bridging architecture and infrastructure shall support automatic and dynamic:

a) shortest transport paths with capability/capacity necessary to meet the requirements

b) loop prevention

c) separation and protection at appropriate levels (e.g., National Institute of Standards and Technology

(NIST) Security controls, Collective governance)

d) traffic distribution (including supporting Provider Bridging (PB))

e) Support for Provider Backbone Bridging (PBB) encapsulation at the DREN Node (6.2.1 Switch Function

(One included))

f) quality of service preservation, prioritization, and pathing

g) topology changes and traffic redistribution around failures

h) Ethernet broadcast and multicast distribution that provides shortest delay and minimizes resource consumption

i) Protection from floods (rate issues) and storms (amplification issues)

Basic STP [Spanning Tree Protocol] is not sufficient to meet the above requirements. Other technologies such as Shortest Path Bridging (SPB), TRansparent Interconnection of Lots of Links (TRILL), Equal-Cost Multi-Path

(ECMP), or Ethernet Virtual Private Network (EVPN) could be configured to meet or exceed the requirements.

The requirements are not written to constrain the Contractor to one of these standards or one vendor implementation. The Government will specify which Switch Functions are edge (not used for transit traffic between other Nodes); all others are middle (used for transit). The Contractor shall deploy and configure

Switch Functions to ensure edge Switch Functions are ineligible for transit traffic.

6.1.1.2. Multicast

The network shall support Ethernet broadcast and multicast. The implementation must minimize how much broadcast and multicast traffic is replicated over a given path for each VLAN. Bifurcation shall occur within the

DCNs (the DREN core), not at the edge (SDP/DXP).

To properly transport IPv6 multicast Ethernet frames, all layer 2 switching functions in the network shall fully support MLD snooping and MLDv2. To properly transport IPv4 multicast Ethernet frames, all layer 2 switching functions in the network shall fully support IGMP snooping and IGMPv3.

6.1.1.3. Ethernet Quality of Service (QOS)

End-to-end Quality of Service (QoS) controls shall be implemented across the DREN Network. At the Ethernet layer, 802.1p priority levels shall be supported. Although marking of any of the eight values shall be used to appropriately order and route the frame, it is understood that Network Control (NC) at the transport level is reserved for other than DREN Subscriber traffic. The marking of NC must be preserved but transported as if marked at the next highest level. At all elements of switching function, the priority shall be used to appropriately order and route the frames.

If Ethernet transport is carried over other protocols the original priorities must be preserved, and mapped to the transport prioritization mechanism so that its prioritization is acted upon at every higher transport function.

6.1.1.4. VLAN

The Ethernet frames will be delivered over 802.1Q "VLANs" at the interface on the DREN Node. Each VLAN, as specified by the Government, shall be configured to transport to the given set of DREN Nodes. The network shall support thousands of such VLANs. Each VLAN shall be totally isolated (logically separate) from all other

VLANs, and shall be protected from accidental leakage between them through automated and/or administrative mechanisms. Each VLAN could be point-to-point, point-to-multipoint, or multipoint-to-multipoint.

6.1.1.5. Encryption

The Ethernet transport shall support encryption. All Ethernet traffic shall be encrypted unless specifically indicated otherwise by the Government. This encryption shall be implemented using MACsec hop-by-hop encryption between Switch Functions that are physically and logically protected for processing non-encrypted

DREN traffic. The encryption can be inherent to the switching function or can be separately applied but shall meet all PWS requirements including transport performance (6.1.0.2) and Ethernet transport requirements

(6.1.1). For traffic specifically designated as not requiring encryption (e.g., already encrypted, test traffic), the solution shall allow for bypass VLANs. In the provider's core, these VLANs shall bypass the hop-by-hop

MACsec imposed path through DCNs and be switched directly to the destination DREN Node(s).

6.1.1.6. Frame Size

The network shall transport Ethernet Frames of at least 9108 bytes (including all 18 bytes of the header and trailer) introduced into a port of a DREN Node. The switches, access links, and provider backbone shall have sufficient frame size capacity to transport those frames end-to-end plus any additional overhead necessary to meet all PWS requirements. The requirements include, for example, MACsec encryption, PB, PBB, and network topology overhead (e.g., SPB, TRILL). This frame size is selected to support Government calculated frame size needs for its largest applications. All elements of transport shall meet at least these frame size requirements.

6.1.1.7. Ethernet Resiliency

The transport bridging protocol shall be sufficient to properly forward frames even in the presence of a failed path, a failed DREN Node (other than the endpoints), or any degraded element that would normally be part of the Ethernet transport. Failures shall result in a new optimized topology that bypasses the degraded or failed element. All requirements for transport shall still be met for all functioning aspects of the network elements.

All DREN Nodes shall have a MACsec and bridging relationship with two or more DCNs. The path used shall be to the nearest DCN. In the event of a DCN failure, the forwarding shall occur to the next nearest DCN.

6.1.2. Internet Protocol (IP) Transport

DREN4 must include an IP Transport Service that routes and delivers IP packets natively end-to-end between and through DREN Nodes. Multiple independent IP networks will be in DREN, some are predefined and others that will be implemented during the life of the contract as needed.

Each IP network must support unicast routing, and may require IP multicast and/or anycast routing as well.

Router Functions in the network may route IP packets between the various IP networks as required, and between Subscriber networks and other external peers.

References to "IP" imply both IPv6 and IPv4 protocols.

IP Transport Services are delivered over Ethernet connections to DREN Subscribers or peers.

All network addressing (prefixes) in use on DREN will be provided by the Government, with the exception of the Outreach service (6.1.2.11.2).

6.1.2.1. IPv6

The primary IP protocol is IP version 6 (IPv6). All IP functionality and services shall fully support IPv6. Some IP networks (6.1.2.8 Multiple IP networks) may require IPv4 support as well, in a "dual stack" configuration, while others will be IPv6-only (e.g., the management networks).

All systems, software, and equipment supporting the network and its services shall support IPv6 capabilities

(including features, performance, and security) in an equivalent or better way than IPv4. The Contractor shall not deploy any systems, software, or equipment on DREN that does not meet this requirement. The

Contractor shall configure all network systems, software, and equipment to utilize IPv6 in an equivalent or better way than IPv4. The Contractor shall have a corporate commitment to IPv6.

6.1.2.2. IPv4

IP version 4 (IPv4) is considered the "legacy IP protocol", and shall be supported on IP networks as needed, but shall not be in use on certain IP networks such as the management networks (6.1.2.8.5 Management

Networks). Where IPv4 is not in use, interfaces of devices connected to the IP network shall not have IPv4 addresses configured on the interface in order to ensure that no IPv4 traffic is generated and so these devices will not respond to any IPv4 traffic that might unintentionally exist on such networks.

6.1.2.3. IP Maximum Transmission Unit (MTU)

The network shall accept, transport, and deliver packets with an IP MTU of at least 9000 bytes, without fragmentation. The Contractor shall configure the IP MTU of any Subscriber facing interface to 9000 bytes unless otherwise directed by the Government. IP MTU refers to the entire IP packet, including the IP header, but not any encapsulating headers or trailers.

Path MTU Discovery shall be supported on all DREN network paths. This includes the proper generation and delivery of Internet Control Message Protocol (ICMP) messages for Packet Too Big (IPv6) and Fragmentation

Needed (IPv4).

6.1.2.4. Unicast

The DREN4 networks shall support the delivery of unicast traffic in all aspects of the IP Service.

6.1.2.5. Multicast

The Contractor shall provide a robust native IPv6 and IPv4 multicast capability both within the DREN community and between DREN and external networks in all phases of the contract. The IP Multicast capability shall include multicast route, source, traffic exchange, and efficient tree management. The capability shall meet the same bandwidth and latency requirements as IP Unicast capability for the multicast path taken. The

IP Multicast capability shall support at a minimum Any Source Multicast (ASM), Source Specific Multicast

(SSM), Protocol Independent Multicast-Sparse-Mode (PIM-SM), Multicast Source Discovery Protocol (MSDP)

Internet Group Management Protocol (IGMP) v3, and Multicast Listener Discovery (MLD) v2. The IP Multicast infrastructure shall perform efficient bifurcation away from the site and be configured to work with underlying

IP routing and Ethernet switching. A rendezvous point (RP) topology shall be designed and implemented for each IP network with sufficient capacity for performance requirements and redundancy to support availability requirements. The IP Multicast capability shall support security and control mechanisms based on best current practices for IP Multicast and shall include the ability to place blocks at external peering, internal peering, or Subscriber interfaces including Border Bootstrap Router (BSR) limit, PIM block, and scoping limits by direction of the Government.

6.1.2.6. Anycast

Anycast, or one-to-one-of-many routing, shall be supported. When multiple hosts share the same destination address, the network shall route traffic destined for that address to the nearest one. The pairing of a given source to its nearest anycast destination shall be stable. Any given pair shall only change when failure of the anycast host or the path to that host occurs. The Contractor shall implement anycast as part of the normal

Border Gateway Protocol (BGP) routing. In addition, for IPv6, the ability to configure "host routes" as discussed in Request for Comments (RFC) 4291 shall be supported.

6.1.2.7. IP Quality of Service (QoS)

End-to-end QoS controls shall be implemented across DREN. At the IP layer, the network shall support RFC

2475 DiffServ, including the Expedited Forwarding (EF) and Assured Forwarding (AF) Per-Hop Behaviors (PHB).

If carried over other protocols at layers below IP, different IP classes of service shall be mapped to lower layer

QoS mechanisms and acted upon (e.g. using PBB-TE [Traffic Engineering], Differential Services (DiffServ) aware

MPLS (MPLS-TE/MPLS-TP [Transport Profile]), or similar, depending on the implementation).

Where routing occurs, the Contractor shall ensure that the IP layer accepts packets that have already been tagged with DiffServ Code Point (DSCP) values and apply the corresponding DiffServ PHB's to them. Where routing occurs, the Contractor shall ensure that IP packets can be initially tagged or retagged with DSCP values based on combinations of protocol, ports, DSCP values, and source and destination addresses.

6.1.2.8. Multiple IP networks

DREN4 shall support multiple IP networks. Each IP network shall be isolated and independent of any other network. IP networks will be interconnected as needed through Router Functions in the network. Private address space (RFC1918), Unique Local Addresses (ULA), and Network Address Translation (NAT) shall not be used on any IP networks. IP networks will be grouped into "Collectives" (6.1.0.1 Collectives).

The current predefined IP networks include "Public External", "DoD Only", and "Non-DoD Access", which shall be implemented as defined below.

6.1.2.8.1. Public External (PX) IP Network

The PX IP network resides within the Internet collective and exists in support of peering with all external non-

DoD networks. The network will carry the full default-free Internet routing table and is the transit network for all DREN connectivity to the Internet and non-DoD private peers. The Contractor shall follow all Internet BCPs.

The PX traffic does not require encryption. Currently, this network operates as part of the Autonomous

System (AS) defined by Autonomous System Number (ASN) 668.

6.1.2.8.2. DoD Only (DO) IP Network

The DO IP network resides in the DoD Collective and exists to route IP traffic for DoD Subscribers and other

DoD networks. It has internal peering relationships with DREN Subscribers, and external peering relationships with other DoD networks (e.g., NIPRnet, Navy/Marine Corps Internet (NMCI)), and carries ONLY DoD routes

(over 15,000 routes). Currently, this network operates as ASN 333.

6.1.2.8.3. Non-DoD Access (ND) Network

The ND network resides in the DoD collective and exists to route IP traffic from DoD Subscribers to the other

Collectives including the Internet. Its only function is to provide IP transport between DoD Subscriber networks and the SGs (6.1.2.9.5) which provide access to other Collectives. It shall not provide transport between DoD Subscribers directly. Currently, this network together with PX operates as ASN 668.

6.1.2.8.4. Extended DMZ (ED) Network

The ED IP Network resides in the DoD Collective and exists to support systems and servers that provide public reachable services to the Internet.

6.1.2.8.5. Management Networks

Management Networks reside in the DoD collective and exist to support management of network devices and systems, and are generally implemented as flat isolated networks to meet security requirements. These networks shall use only IPv6, and shall not carry any IPv4 traffic. All network devices and systems shall be fully functional in an IPv6-only environment, and all management services and protocols must fully support IPv6.

6.1.2.9. IP Routing

IP networks are interconnected using physical or virtual routers. These routers provide IP routing and forwarding functionality as a component of DREN Nodes, primarily DCNs. These routers receive IP packets on one network interface and forward them out a different network interface at high speed based on routing information learned from neighboring devices using various routing protocols. Routers may filter or modify the IP packets in any number of ways before processing them.

6.1.2.9.1. Best Current Practices

IP networks and routers shall perform IP routing and forwarding functions following Internet BCPs and conventions, and operate standard gateway protocols for the exchange of routing information.

6.1.2.9.2. Routing Protocols

Industry standard IP routing protocols shall be employed to distribute routing information between all IP routers in the network.

An IGP, either Open Shortest Path First (OSPF) or Intermediate System – Intermediate System (IS-IS), shall be used for routing within DREN. The IGP shall carry all DREN infrastructure routes. The IGP shall carry sufficient metrics for every link and path to enable routing decisions based on relative distance, hop count, and other network conditions. The Contractor shall permit Government managed devices to participate in the IGP.

An EGP, including MultiProtocol Border Gateway Protocol (MBGP), shall carry the external routing information for all external networks and for DREN Subscriber networks. The EGP shall support Multi-Exit-Discriminators

(MEDs) from Subscribers and external peers to steer traffic between ASs.

The IP routing protocols shall support authentication in compliance with relevant security controls (6.3

Security).

6.1.2.9.3. Peering

In the context of this PWS, "Peering" refers to exchanging routing information with other networks via an EGP.

DREN seeks to have rich external peering. DREN will establish connectivity to external networks where there is benefit to DREN and its Subscribers. DREN does not operate as a Tier-1 ISP. For connectivity to any other external network, the Government may use the 6.1.2.11 Internet Transit Service (ITS).

The Government intends to have the PX IP network peer with other research and educational networks, with other Federal Agency networks, and with other networks that are determined to be beneficial to DREN. The

Government primarily intends to connect external peers at the DXPs, but the Contractor shall support physical connections to external peers at any DREN Node.

The Government intends to have the DO IP network peer with other external DoD networks using MBGP, including NIPRNet at three locations.

Internal peering with DREN Subscriber networks will exist via connections at SDPs. The Contractor shall support Subscribers:

a) being able to logically connect to one or more IP networks

b) using static IP routing on no more than one of their IP connections to DREN

c) using MBGP to exchange routing information and to make routing decisions

A very common Subscriber configuration will include IP connections to both the DO and ND networks, will use

MBGP to exchange routing information with the DO network, and will use either static or MBGP routing with the ND network. The Government will provide direction to the Contractor on how to configure each

Subscriber's IP…