HR001118S0051.pdf

Broad Agency Announcement Searchlight

HR001118S0051

August 23, 2018

Defense Advanced Research Projects Agency Information Innovation Office 675 North Randolph Street Arlington, VA 22203-2114

HR001118S0051 SEARCHLIGHT 2

Table of Contents

I. Funding Opportunity Description

A. Introduction/Background

B. Program Description/Scope

C. Program Structure

D. Technical Areas

E. Program Goals and Metrics

F. Schedule/Milestones

G. Deliverables

H. Government-furnished Property/Equipment/Information

I. Intellectual Property

J. Clearance Requirements

II. Award Information

A. Awards

B. Fundamental Research

C. Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls

III. Eligibility Information

A. Eligible Applicants

B. Organizational Conflicts of Interest

C. Cost Sharing/Matching

IV. Application and Submission Information

A. Address to Request Application Package

B. Content and Form of Application Submission

C. Submission Date and Time

D. Funding Restrictions

E. Other Submission Requirements

V. Application Review Information

A. Evaluation Criteria

B. Review and Selection Process

VI. Award Administration Information

A. Selection Notices

B. Administrative and National Policy Requirements

C. Reporting

HR001118S0051 SEARCHLIGHT 3

VII. Agency Contacts

VIII. Other Information

A. Frequently Asked Questions (FAQs)

B. Collaborative Efforts/Teaming

C. Proposers Day

D. Submission Checklist

E. Associate Contractor Agreement (ACA)

HR001118S0051 SEARCHLIGHT 4

PART I: OVERVIEW INFORMATION

Federal Agency Name: Defense Advanced Research Projects Agency (DARPA), Information Innovation Office (I2O)

Funding Opportunity Title: Searchlight

Announcement Type: Initial Announcement

Funding Opportunity Number: HR001118S0051

Catalog of Federal Domestic Assistance Numbers (CFDA): 12.910 Research and Technology Development

Dates o Posting Date: August 23, 2018 o Proposers Day: August 24, 2018 o Abstract Due Date: September 6, 2018, 12:00 noon (ET) o Proposal Due Date: October 17, 2018, 12:00 noon (ET) o BAA Closing Date: October 17, 2018, 12:00 noon (ET)

Anticipated Individual Awards: DARPA anticipates multiple awards for Technical Area 1 and a single award for Technical Area 2.

Total Funding Available for Award: The total funding amount for Searchlight is anticipated to be $18M.

Types of Instruments that May be Awarded: Procurement contracts, cooperative agreements or Other Transactions

Agency Contacts o Technical POC: Jonathan Smith, Program Manager, DARPA/I2O o BAA Email: Searchlight@darpa.mil o BAA Mailing Address:

DARPA/I2O

ATTN: HR001118S0051

675 North Randolph Street Arlington, VA 22203-2114 o I2O Solicitation Website: http://www.darpa.mil/work-with-us/opportunities http://www.darpa.mil/work-with-us/opportunities

HR001118S0051 SEARCHLIGHT 5

PART II: FULL TEXT OF ANNOUNCEMENT

I. Funding Opportunity Description

DARPA is soliciting innovative research proposals in the area of Internet-scale network quality of service management for distributed applications. Proposed research should investigate innovative approaches that enable revolutionary advances in science, devices, or systems.

Specifically excluded is research that primarily results in evolutionary improvements to the existing state of practice.

This Broad Agency Announcement (BAA) is being issued, and any resultant selection will be made, using procedures under Federal Acquisition Regulation (FAR) 6.102(d)(2) and 35.016.

Any negotiations and/or awards will use procedures under FAR 15.4 (or 32 CFR § 200.203 for cooperative agreements). Proposals received as a result of this BAA shall be evaluated in accordance with evaluation criteria specified herein through a scientific review process.

DARPA BAAs are posted on the Federal Business Opportunities (FBO) website (https://www.fbo.gov/) and the Grants.gov website (http://www.grants.gov/).

The following information is for those wishing to respond to this BAA.

Proposers may make submissions to multiple technical areas (TAs). However, each proposal should address only one technical area. Due to the symbiotic nature of the work being done between the two TAs, the same proposer can perform work under both TA1 and TA2.

A. Introduction/Background

Approaches to specifying and controlling network quality of service (QoS) for distributed applications have not been deployed at scale. Reasons for this are manifold, and have included:

(1) the complexity of decentralized resource control in a federated Internet; and

(2) the demonstrated effectiveness of protocols such as Transmission Control

Protocol/Internet Protocol (TCP/IP) in exploiting and sharing the available capacity amongst networked applications.

Distributed applications are increasingly important tools for managing global enterprises, as they improve both the speed and scale of decision-making, learning and other needs faced by the enterprise. For example, a now-common means of collaborative document authoring is sharing a document that immediately reflects changes made by any writer or editor. Enterprise-wide communication systems use the Internet to interconnect sites and create a global substrate for the Enterprise’s distributed applications.

Application instances that share paths between sites (“enclaves”) are subject to resource starvation due to surges in demand for network capacity arising from demands on the enterprise.

The Internet’s protocols are designed to provide each application a “fair share” of the scarce resource (network capacity). An enterprise’s applications and user communities, on the other hand, can often be prioritized, using criteria such as risk, cost, and profit. Thus, mechanisms for intra-organization allocation of Internet resources, which are inherently limited, are needed.

https://www.fbo.gov/ http://www.grants.gov/

HR001118S0051 SEARCHLIGHT 6

For example, a chat-based application used to coordinate amongst an enterprise’s leaders and their direct reports should be favored over other traffic that the enterprise may permit the use of during breaks and other periods, e.g., entertainment such as games and videos.

Existing approaches to managing resources allocated to instances of distributed applications have either been limited to managed enclaves at the network edge that can prioritize all traffic between end hosts or by specialized network support (e.g., dedicated links, label-switching approaches, such as Asynchronous Transfer Mode (ATM) and Multiprotocol Label Switching (MPLS), etc.) between enclave ingress/egress points. Considerations including complexity, federation, interoperability, and financial cost preclude this approach at scale.

Techniques have been developed that are effective in adapting to network dynamics on the Internet. By design, these approaches treat the Internet as almost completely opaque to observation and its phenomenology almost impossible to control, and thus largely rely on the use of compensatory enhancements in end-host stacks. For example, a proxy (such as a gateway, middlebox or virtual appliance positioned at an enclave boundary) can enforce priorities for hosts within the enclave, but as a consequence of being limited to the network edge must attend to inter-enclave Internet dynamics such as contention, queuing, congestion, and loss. The increasing use of network traffic encryption impacts these approaches, as their decision processes require access to traffic contents.

The Searchlight program seeks novel approaches to analysis and QoS management of an enterprise’s distributed applications overlaid on the Internet; proposed approaches must reflect priorities while minimizing impacts on other applications. Proposals should provide a brief overview of the state-of-the-art. Additionally, proposals should justify how the technical approach advances the state of current technology.

B. Program Description/Scope

The Searchlight program seeks novel approaches to translating an enterprise’s static and dynamic priorities to management of distributed applications overlaid on the Internet. Consider the notional concept of operations in Figure 1. Assume a distributed enterprise is using the Internet to support both high-priority C-level chat application traffic, and low-priority training application traffic.

HR001118S0051 SEARCHLIGHT 7

Figure 1: Notional Searchlight Concept of Operations (CONOPS)

If the traffic from both applications uses the same network resources (such as network paths, switches, etc.), lower priority traffic may degrade the chat application’s response to an unacceptable level.

The goal of the Searchlight program is to develop techniques and systems that enable the enterprise to temporarily decrease the QoS for low-priority application traffic internal to that organization, resulting in sufficient QoS for the organization’s high-priority traffic.

Figure 1 illustrates the interaction between high-priority chat traffic (blue) and low priority but high-volume video training traffic (green). In this example, the Searchlight system would lower the resources used by the training application to ensure adequate performance for chat, while limiting the QoS reduction of the training system to a minimally acceptable 2-second interactive response times. Searchlight would also avoid effects on and interference with network traffic from other entities and organizations using the Internet (the rectangle in Figure 1).

The advent of programmable network elements such as software-defined network switches operating in the wide-area (SD-WAN), the ever-improving capabilities of machine-learning algorithms and steady increases in computational power and storage capacity, in combination, enable this important problem to be addressed at Internet scale. Results from research performed in the Searchlight program will demonstrate that unmodified distributed applications instances overlaid on the Internet can be prioritized at runtime to reflect an enterprise’s current goals by adjusting network behavior amongst those applications to meet those goals.

C. Program Structure

Searchlight is a four-year program organized into three phases.

Phase 1 develops an initial Searchlight capability at laboratory scale (100 nodes) at the end of 18 months.

HR001118S0051 SEARCHLIGHT 8

Phase 2, also 18 months, refines the Searchlight system to simultaneously increase analytic accuracy and precision, while demanding a 10x increase in scale, to 1,000 nodes.

Phase 3, which will be 12 months, is focused on three 4-month evaluation and refinement spirals with 10,000 nodes.

Each Phase demands increased accuracy of identification and increased precision in meeting the goals of the enterprise while increasing the challenges of scale and fortunate/(or unfortunate) placement in the network graph.

An independent team will be providing the test and evaluation range. As mentioned previously, the range will increase in scale over the program phases. The range’s topology, including location, number, and type of network resources available to Searchlight, will be designed by this team to maximize realism given the scale of the range. Additionally, this team will specify the parameters required by Searchlight performers for development, experimentation, and evaluation. Such parameters are time-varying and include the enterprise’s high and low priority applications and endpoints, their priorities and flow volumes, as well as cross-traffic applications, endpoints, and flow volumes. Evaluation metrics are discussed below.

In order to support collaboration and the development of technology and systems in the Searchlight program, performers will have Associate Contractor Agreement (ACA) language included in their award (see Section VIII.E). This ACA is intended to ensure appropriate coordination and potential integration of work done by program performers.

D. Technical Areas

Figure 2: Searchlight Technical Area 1 and Technical Area 2

HR001118S0051 SEARCHLIGHT 9

Technical challenges for Searchlight include:

accurately identifying specific applications that are multiplexed with other application traffic;

achieving necessary accuracy in identifying applications from encrypted traffic;

deducing the interconnection graph of interacting users in an identified instance of the application;

identifying available policing resources (e.g., IP routers equipped with active queue management) in the graph;

selecting one or more resources along with durations of use sufficient to achieve enterprise priorities;

actuating the queue management resource; and determining if the goals of the enterprise were achieved.

Searchlight has been organized to address these challenges in two technical areas (TAs). It is assumed that technical progress on TA1 (focused on network analysis requirements in the bullet list above) and TA2 (focused on implementing the enterprise’s goals) will be proceeding in parallel. While the technical challenges are separable, the two technical areas are by necessity integrated, as no management can take place without a policy and application instance to which it can be applied. The interaction between these roles is illustrated in Figure 2.

TA1: Applications and Network Analytics

Searchlight TA1 is focused on network traffic analysis. Proposers should assume an Internet setting with a mixture of network elements, as in the graphic on the left side of Figure 2. For TA1, the relevant network element types are conventional routers (illustrated as blue boxes) and Searchlight Analysis devices (illustrated as yellow circles).

Proposers should assume that the number, location, and connectivity of Searchlight Analysis devices is constrained, to reflect the realities of a deployed Searchlight system, including cost, commercial availability of desired connectivity and geopolitical limitations on placement. While any specific test network or real-world deployment will require rich detail, such as network graphs represented as adjacency lists, etc., the Searchlight program’s quantification of this constraint is node coverage, defined as the fraction of conventional routers from which Searchlight Analysis devices can extract observables such as flow statistics, logs, etc. Thus, if in a network with 100 conventional routers, necessary observables can be extracted from 10, the node coverage is calculated as 10%, and if 50 routers can supply the observables needed to the set of Searchlight Analysis devices, 50% node coverage is achieved.

To preserve the viability of Searchlight in the face of increasing use of encryption, all packet bodies must be assumed to be encrypted, leaving only metadata required for routing visible, as well as observables available from network devices such as byte counts and timer values.

Successful TA1 proposals, in spite of this limitation, will propose algorithms and methodologies to extract information concerning distributed applications, specifically:

(1) identification of applications using available observables such as packet sizes, interarrival delays, protocol responses to loss, and communications patterns such as unicast, multicast and broadcast

HR001118S0051 SEARCHLIGHT 10

(2) path and link characteristics such as the presence, location, persistence, and capacity limits of bottlenecks

(3) identification of flows associated with distinct instances of the application, and

(4) the nodes and users involved in that application instance.

Additional analytic challenges include overcoming feature blurring due to multiplexing (if dataplane analytics are used), novel emergent applications and application instances with lifetimes shorter than the time required for Searchlight to identify applications and their network characteristics.

Measures of success (metrics) include accuracy in identifying specific networked applications, accuracy in inferring network topology/connectivity and maintenance of accuracy in the face of concurrent increases in network scale and decreases in Searchlight node visibility.

TA2: Network Resource Management

The objective of TA2 is the use of available resources, such as conventional routers equipped with standardized feature sets, or software-defined networking (SDN) devices used as virtual appliances, to manage network applications. To successfully execute this task, TA2 must consider the priorities and goals of the enterprise, relevant application and network characteristics provided by TA1, and the network resources available to generate and execute a plan that adapts network behavior to support the mission. The execution of this plan MUST NOT affect the performance of other entities using the network.

As an illustrative example, consider Active Queue Management (AQM), a function available on many commercial IP routers. A variety of methods to perform AQM are described in the technical literature; objectives of these methods include avoiding congestion losses by acting before queues overflow and fair allocation of shared capacity; the “active” act is dropping enqueued packets.

The increased control required to achieve the enterprise’s goals and priorities creates new challenges that demand significant advances in the state of the art in managing network traffic.

Examples include the need for fine-grained discrimination amongst flows that can operate at line rate, queue management algorithms that can shape the queue management in response to changing conditions on the network, or breakthrough approaches that exploit emerging network capabilities such as software-defined Active Router Control and programmable accelerators using technologies such as field-programmable gate arrays or Graphics Processing Unit (GPU)-like manycore approaches. As different circumstances may have distinct demands, multiple, diverse methods are preferable due to the diversity of real-world applications and networks in use across the Internet.

Searchlight will develop complete integrated systems. DARPA expects performers to:

coordinate to define interfaces between the technical areas;

construct integrated systems; and support both project-level and system-level testing and evaluation.

As stated previously, testing and evaluation will be conducted by an independent team.

HR001118S0051 SEARCHLIGHT 11

E. Program Goals and Metrics

Searchlight’s goal is to develop systems capable of operating at Internet scale. Hence as the program progresses, we expect TA1 and TA2 capabilities to increase with respect to both scale and performance. The TA1 metrics are focused on discovery and identification of applications and uses in the Internet. As the Searchlight program advances, scale (as measured in the number of network elements in use) is increased by a factor of 10 with each phase transition.

As identification of applications and the sets of paths that an application is using is, in essence, a pattern recognition problem, we have used precision and recall to measure TA1 performance. As distributed applications are instantiated and terminated, they use a set of network elements (e.g., the conventional routers discussed above). For any network graph identified by TA1, the objective is to identify exactly this set of nodes, the relevant elements. As the TA1 algorithm presents selections of nodes associated with a particular application instance, we calculate the precision, a quantification of how many selected elements are relevant, as (true positives) / (true positives + false positives) and the recall, a quantification of how many relevant elements are selected, as (true positives) / (true positives + false negatives). The ability for a TA1 technology to accurately infer this information is dependent on the proportion of Searchlight resources available in the network, as well as their connectivity with respect to relevant traffic. The TA1 node coverage metric is the number of Searchlight nodes divided by the total number of nodes in the network used by a given set of application flows.

TA2 improves QoS for high-priority applications by degrading QoS for lower-priority applications. Hence the TA2 metrics measure the tradeoffs necessary to achieve the required performance. Specifically, Searchlight goals over the program are to progressively increase QoS for the important applications while progressively limiting performance loss of the less-important applications. At the end of Phase 1, TA2 network management techniques should yield a QoS performance gain of 25%. To evaluate the generality of TA2 components, QoS improvement will be measured for three applications, which will be chosen by the independent evaluation team. QoS performance gain is expected to reach 100% by the end of the program.

Similarly, limits on performance loss for low-priority applications will be tightened over the program phases. By the end of the program, QoS delays of 2.2 seconds for low-priority applications will be considered acceptable. Note that any network management actions executed by TA2 MUST NOT affect the performance of other entities using the network.

Goals for the technical areas and the program are shown in Figure 3. Program goals are metrics for integrated TA1/TA2 systems; Searchlight systems should increase QoS for high-priority applications from 10% to 50% over the program. Additionally, the generality of the integrated systems will be evaluated by increasing the number of high-priority applications tested as the program progresses.

HR001118S0051 SEARCHLIGHT 12

Figure 3: Searchlight Program Goals

F. Schedule/Milestones

DARPA will conduct quarterly technical reviews, comprised of biannual Principal Investigator (PI) meetings and biannual site visits, during which the program management team will assess progress towards a solution via performer briefings and technical exchanges. For cost estimation purposes, assume that the locations for PI meetings will alternate between Los Angeles, CA, and Washington, DC. Program evaluation will be conducted by the Government team throughout program execution. The program schedule and milestones are shown in Figure 4 below.

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 Evaluations • • • Demonstrations • • • Evaluations • • • Demonstrations • • • TA1/TA2 Interface • • • TA1/TA2 Integration Plan • • • TA1/TA2 Integration • • • TA1/TA2 Integrated Evaluations • • • TA1/TA2 Integrated Demonstrations • • •

• • • • • • • •Site Visits

TA

TA

Pr og ra m

: T A1 an d

TA

Kickoff and PI Meetings

Phase 1 Phase 2 Phase 3 Program Month

Figure 4: Program Schedule/Milestones

HR001118S0051 SEARCHLIGHT 13

G. Deliverables

All performers will be required to provide, at a minimum, the following deliverables:

Any technical papers derived from work funded by Searchlight

Commented source code, any other necessary data, build scripts, and documentation (including at minimum user manuals and a detailed software design document) for all software developed under this program

Annotated slide presentations must be delivered within 30 calendar days after kickoff meeting and after each program event

Monthly technical status reports detailing progress made, tasks accomplished, major risks, planned activities, trip summaries, changes to key personnel, and any potential issues or problem areas that require the attention of the Government Team must be provided within ten (10) calendar days of the end of each calendar month

Monthly financial status reports must be provided within ten (10) calendar days of the end of each calendar month

A final phase report for each program phase that concisely summarizes the effort conducted, technical achievements, and remaining technical challenges will be due 30 calendar days after the end of each phase

A final report at the end of the overall period of performance that summarizes the project

H. Government-furnished Property/Equipment/Information

Proposals should clearly state any assumptions regarding the use of proposed Government test facilities and capabilities, as well as any proposed Government-furnished Equipment used as part of their development, test, and evaluation approach.

I. Intellectual Property

The Searchlight program will emphasize creating and leveraging open source technology and architectures to ease technology transition. Intellectual property rights asserted by proposers are strongly encouraged to be aligned with open source regimes. See Section VI.B.1 for more details on intellectual property.

A key goal of the program is to establish an open, standards-based, multi-source, plug-and-play architecture that allows for interoperability and integration. This includes the ability to easily add, remove, substitute, and modify software and hardware components. This will facilitate rapid innovation by providing a base for future users or developers of program technologies and deliverables. Therefore, it is desired that all noncommercial software (including source code), software documentation, hardware designs and documentation, and technical data generated by the program be provided as deliverables to the Government, with a minimum of Government Purpose Rights (GPR), as lesser rights may adversely impact the lifecycle costs of affected items, components, or processes.

HR001118S0051 SEARCHLIGHT 14

J. Clearance Requirements

DARPA expects that all technical work for both TA1 and TA2 will be entirely unclassified for the duration of the Searchlight program, as this is needed for the open source approach discussed in Section I. However, as a major Searchlight programmatic goal is rapid technology transition and opportunities may include U.S. Military networks, the PI and key personnel for TA2 proposals must possess current security clearances at the SECRET level. There are no personnel clearance requirements for TA1.

HR001118S0051 SEARCHLIGHT 15

II. Award Information

A. Awards

Multiple awards are anticipated. The level of funding for individual awards made under this solicitation has not been predetermined and will depend on the quality of the proposals received and the availability of funds. Awards will be made to proposers whose proposals are determined to be the most advantageous to the Government, all factors considered, including the potential contributions of the proposed work, overall funding strategy, and availability of funding. See Section V for further information.

The Government reserves the right to:

select for negotiation all, some, one, or none of the proposals received in response to this solicitation;

make awards without discussions with proposers;

conduct discussions with proposers if it is later determined to be necessary;

segregate portions of resulting awards into pre-priced options;

accept proposals in their entirety or to select only portions of proposals for award;

fund proposals in increments and/or with options for continued work at the end of one or more phases;

request additional documentation once the award instrument has been determined (e.g., representations and certifications); and remove proposers from award consideration should the parties fail to reach agreement on award terms within a reasonable time or the proposer fails to provide requested additional information in a timely manner.

Proposals selected for award negotiation may result in a procurement contract, cooperative agreement, or Other Transaction (OT) depending upon the nature of the work proposed, the required degree of interaction between parties, and other factors.

Proposers looking for innovative, commercial-like contractual arrangements are encouraged to consider requesting Other Transactions. To understand the flexibility and options associated with Other Transactions, consult http://www.darpa.mil/work-with-us/contract-management#OtherTransactions.

In accordance with 10 U.S.C. § 2371b(f), the Government may award a follow-on production contract or Other Transaction (OT) for any OT awarded under this BAA if: (1) that participant in the OT, or a recognized successor in interest to the OT, successfully completed the entire prototype project provided for in the OT, as modified; and (2) the OT provides for the award of a follow-on production contract or OT to the participant, or a recognized successor in interest to the OT.

In all cases, the Government contracting officer shall have sole discretion to select award instrument type, regardless of instrument type proposed, and to negotiate all instrument terms and conditions with selectees. DARPA will apply publication or other restrictions, as necessary, if it determines that the research resulting from the proposed effort will present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Any award resulting from such a determination will include a requirement for DARPA permission before publishing any information or results on the http://www.darpa.mil/work-with-us/contract-management#OtherTransactions http://www.darpa.mil/work-with-us/contract-management#OtherTransactions

HR001118S0051 SEARCHLIGHT 16

program. For more information on publication restrictions, see the section below on Fundamental Research.

B. Fundamental Research

It is DoD policy that the publication of products of fundamental research will remain unrestricted to the maximum extent possible. National Security Decision Directive (NSDD) 189 defines fundamental research as follows:

‘Fundamental research’ means basic and applied research in science and engineering, the results of which ordinarily are published and shared broadly within the scientific community, as distinguished from proprietary research and from industrial development, design, production, and product utilization, the results of which ordinarily are restricted for proprietary or national security reasons.

As of the date of publication of this BAA, the Government expects that program goals as described herein may be met by proposers intending to perform fundamental research and proposers not intending to perform fundamental research or the proposed research may present a high likelihood of disclosing performance characteristics of military systems or manufacturing technologies that are unique and critical to defense. Based on the nature of the performer and the nature of the work, the Government anticipates that some awards will include restrictions on the resultant research that will require the awardee to seek DARPA permission before publishing any information or results relative to the program.

Proposers should indicate in their proposal whether they believe the scope of the research included in their proposal is fundamental or not. While proposers should clearly explain the intended results of their research, the Government shall have sole discretion to select award instrument type and to negotiate all instrument terms and conditions with selectees. Appropriate clauses will be included in resultant awards for non-fundamental research to prescribe publication requirements and other restrictions, as appropriate. This clause can be found at http://www.darpa.mil/work-with-us/additional-baa.

For certain research projects, it may be possible that although the research being performed by the awardee is restricted research, a subawardee may be conducting fundamental research. In those cases, it is the awardee’s responsibility to explain in their proposal why its subawardee’s effort is fundamental research

C. Disclosure of Information and Compliance with Safeguarding Covered Defense Information Controls

The following provisions and clause apply to all solicitations and contracts; however, the definition of “controlled technical information” clearly exempts work considered fundamental research and therefore, even though included in the contract, will not apply if the work is fundamental research.

DFARS 252.204-7000, “Disclosure of Information” DFARS 252.204-7008, “Compliance with Safeguarding Covered Defense Information Controls” DFARS 252.204-7012, “Safeguarding Covered Defense Information and Cyber Incident Reporting” http://www.darpa.mil/work-with-us/additional-baa

HR001118S0051 SEARCHLIGHT 17

The full text of the above solicitation provision and contract clauses can be found at http://www.darpa.mil/work-with-us/additional-baa#NPRPAC.

Compliance with the above requirements includes the mandate for proposers to implement the security requirements specified by National Institute of Standards and Technology (NIST) Special Publication (SP) 800-171, “Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations” (see https://doi.org/10.6028/NIST.SP.800-171r1) that are in effect at the time the BAA is issued.

For awards where the work is considered fundamental research, the contractor will not have to implement the aforementioned requirements and safeguards; however, should the nature of the work change during performance of the award, work not considered fundamental research will be subject to these requirements.

http://www.darpa.mil/work-with-us/additional-baa#NPRPAC https://doi.org/10.6028/NIST.SP.800-171r1

HR001118S0051 SEARCHLIGHT 18

III. Eligibility Information

A. Eligible Applicants

DARPA welcomes engagement from all responsible sources capable of satisfying the Government's needs, including academia (colleges and universities); businesses (large, small, small disadvantaged, etc.); other organizations (including non-profit); entities (foreign, domestic, and government); FFRDCs; minority institutions; and others.

DARPA welcomes engagement from non-traditional sources in addition to current DARPA performers.

1. Federally Funded Research and Development Centers (FFRDCs) and Government Entities

a. FFRDCs FFRDCs are subject to applicable direct competition limitations and cannot propose to this BAA in any capacity unless they meet the following conditions: (1) FFRDCs must clearly demonstrate that the proposed work is not otherwise available from the private sector. (2) FFRDCs must provide a letter on official letterhead from their sponsoring organization citing the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and their compliance with the associated FFRDC sponsor agreement’s terms and conditions. This information is required for FFRDCs proposing to be awardees or subawardees.

b. Government Entities Government Entities (e.g., Government/National laboratories, military educational institutions, etc.) are subject to applicable direct competition limitations. Government entities must clearly demonstrate that the work is not otherwise available from the private sector and provide written documentation citing the specific statutory authority and contractual authority, if relevant, establishing their ability to propose to Government solicitations.

c. Authority and Eligibility At the present time, DARPA does not consider 15 U.S.C. § 3710a to be sufficient legal authority to show eligibility. While 10 U.S.C.§ 2539b may be the appropriate statutory starting point for some entities, specific supporting regulatory guidance, together with evidence of agency approval, will still be required to fully establish eligibility. DARPA will consider FFRDC and Government entity eligibility submissions on a case-by-case basis; however, the burden to prove eligibility for all team members rests solely with the proposer.

2. Foreign Participation Non-U.S. organizations and/or individuals may participate to the extent that such participants comply with any necessary nondisclosure agreements, security regulations, export control laws, and other governing statutes applicable under the circumstances.

HR001118S0051 SEARCHLIGHT 19

B. Organizational Conflicts of Interest

FAR 9.5 Requirements In accordance with FAR 9.5, proposers are required to identify and disclose all facts relevant to potential OCIs involving the proposer’s organization and any proposed team member (subawardee, consultant). Under this Section, the proposer is responsible for providing this disclosure with each proposal submitted to the BAA. The disclosure must include the proposer’s, and as applicable, proposed team member’s OCI mitigation plan. The OCI mitigation plan must include a description of the actions the proposer has taken, or intends to take, to prevent the existence of conflicting roles that might bias the proposer’s judgment and to prevent the proposer from having unfair competitive advantage. The OCI mitigation plan will specifically discuss the disclosed OCI in the context of each of the OCI limitations outlined in FAR 9.505-1 through FAR 9.505-4.

Agency Supplemental OCI Policy In addition, DARPA has a supplemental OCI policy that prohibits contractors/performers from concurrently providing Scientific Engineering Technical Assistance (SETA), Advisory and Assistance Services (A&AS) or similar support services and being a technical performer.

Therefore, as part of the FAR 9.5 disclosure requirement above, a proposer must affirm whether the proposer or any proposed team member (subawardee, consultant) is providing SETA, A&AS, or similar support to any DARPA office(s) under: (a) a current award or subaward; or (b) a past award or subaward that ended within one calendar year prior to the proposal’s submission date.

If SETA, A&AS, or similar support is being or was provided to any DARPA office(s), the proposal must include:

The name of the DARPA office receiving the support;

The prime contract number;

Identification of proposed team member (subawardee, consultant) providing the support; and An OCI mitigation plan in accordance with FAR 9.5.

Government Procedures In accordance with FAR 9.503, 9.504 and 9.506, the Government will evaluate OCI mitigation plans to avoid, neutralize or mitigate potential OCI issues before award and to determine whether it is in the Government’s interest to grant a waiver. The Government will only evaluate OCI mitigation plans for proposals that are determined selectable under the BAA evaluation criteria and funding availability.

The Government may require proposers to provide additional information to assist the Government in evaluating the proposer’s OCI mitigation plan.

If the Government determines that a proposer failed to fully disclose an OCI; or failed to provide the affirmation of DARPA support as described above; or failed to reasonably provide additional information requested by the Government to assist in evaluating the proposer’s OCI mitigation plan, the Government may reject the proposal and withdraw it from consideration for award.

HR001118S0051 SEARCHLIGHT 20

C. Cost Sharing/Matching

Cost sharing is not required; however, it will be carefully considered where there is an applicable statutory condition relating to the selected funding instrument (e.g., OTs under the authority of 10 U.S.C. § 2371).

HR001118S0051 SEARCHLIGHT 21

IV. Application and Submission Information

A. Address to Request Application Package

This document contains all information required to submit a response to this solicitation. No additional forms, kits, or other materials are needed except as referenced herein. No request for proposal (RFP) or additional solicitation regarding this opportunity will be issued, nor is additional information available except as provided at the Federal Business Opportunities website (https://www.fbo.gov), the Grants.gov website (http://www.grants.gov/), or referenced herein.

B. Content and Form of Application Submission

1. Abstracts Proposers are highly encouraged to submit an abstract in advance of a proposal to minimize effort and reduce the potential expense of preparing an out of scope proposal. The abstract provides a synopsis of the proposed project, including brief answers to the following questions:

What is the proposed work attempting to accomplish or do?

How is it done today, and what are the limitations?

Who or what will be affected and what will be the impact if the work is successful?

How much will it cost, and how long will it take?

DARPA will respond to abstracts with a statement as to whether DARPA is interested in the idea. If DARPA does not recommend the proposer submit a full proposal, DARPA will provide feedback to the proposer regarding the rationale for this decision. Regardless of DARPA’s response to an abstract, proposers may submit a full proposal. DARPA will review all full proposals submitted using the published evaluation criteria and without regard to any comments resulting from the review of an abstract.

Abstract Format: Abstracts shall not exceed a maximum of 5 pages including the cover sheet and all figures, tables, and charts. The page limit does not include a submission letter (optional).

As a reminder, each abstract submitted in response to this BAA shall address only one TA.

Organizations may submit multiple abstracts to any one TA, or they may submit abstracts to multiple TAs.

All pages shall be formatted for printing on 8-1/2 by 11 inch paper with 1-inch margins and font size not smaller than 12 point. Font sizes of 8 or 10 point may be used for figures, tables, and charts. Document files must be in .pdf, .odx, .doc, .docx, .xls, or .xlsx formats.

Submissions must be written in English. All pages should be numbered.

Abstracts must include the following components:

Cover Sheet: Provide the administrative and technical points of contact (name, address, phone, email, lead organization). Include the BAA number, title of the proposed project, https://www.fbo.gov/ http://www.grants.gov/

HR001118S0051 SEARCHLIGHT 22

primary subcontractors, estimated cost, duration of the project, and the label “Abstract.”

Goals and Impact: Describe what is being proposed and what difference it will make (qualitatively and quantitatively) if successful. Describe the innovative aspects of the project in the context of existing capabilities and approaches, clearly delineating the relationship of this work to any other projects from the past and present.

Technical Plan: Outline and address all technical challenges inherent in the approach and possible solutions for overcoming potential problems. Provide appropriate specific milestones (quantitative, if possible) at intermediate stages of the project to demonstrate progress.

Capabilities/Management Plan: Provide a brief summary of expertise of the team, including subcontractors and key personnel. Identify a principal investigator for the project and include a description of the team’s organization including roles and responsibilities. Describe the organizational experience in this area, existing intellectual property required to complete the project, and any specialized facilities to be used as part of the project. List Government-furnished property, facilities, or data assumed to be available. If desired, include a brief bibliography with links to relevant papers, reports, or resumes of key performers. Do not include more than two resumes as part of the abstract. Resumes count against the abstract page limit.

Statement of Work, Cost and Schedule: Provide a cost estimate for resources over the proposed timeline of the project, broken down by year. Provide cost estimates for each subcontractor. All costs may be a rough order of magnitude.

2. Proposals Proposals consist of Volume 1: Technical and Management Proposal (including mandatory Appendix A and optional Appendix B); Volume 2: Cost Proposal; the Level of Effort Summary by Task Excel spreadsheet; and the PowerPoint summary slide.

All pages shall be formatted for printing on 8-1/2 by 11-inch paper with 1-inch margins, single-line spacing, and a font size not smaller than 12 point. Font sizes of 8 or 10 point may be used for figures, tables, and charts. Document files must be in .pdf, .odx, .doc, .docx, .xls, or .xlsx formats. Submissions must be written in English. All pages of Volume 1 should be numbered.

A summary slide of the proposed effort, in PowerPoint format, should be submitted with the proposal. A template slide is provided as an attachment to the BAA. Submit this PowerPoint file in addition to Volumes 1 and 2 of your full proposal, and the Level of Effort Summary by Task Excel spreadsheet. This summary slide does not count towards the total page count.

Reminder – Each proposal submitted in response to this BAA shall address only one TA.

Organizations may submit multiple proposals to any one TA, or they may propose to multiple TAs.

Proposals not meeting the format prescribed herein may not be reviewed.

HR001118S0051 SEARCHLIGHT 23

a. Volume 1: Technical and Management Proposal The maximum page count for Volume 1 is 25 pages, including all figures, tables and charts ,but not including the cover sheet, table of contents or appendices. A submission letter is optional and is not included in the page count. Appendix A does not count against the page limit and is mandatory.

Appendix B does not count against the page limit and is optional. Additional information not explicitly called for here must not be submitted with the proposal, but may be included in the bibliography in Appendix B. Such materials will be considered for the reviewers’ convenience only and not evaluated as part of the proposal.

Volume 1 must include the following components:

i. Cover Sheet: Include the following information.

Label: “Proposal: Volume 1” BAA number (HR001118S0051) Technical Area Proposal title Lead organization (prime contractor) name Type of organization, selected from the following categories: Large Business, Small Disadvantaged Business, Other Small Business, HBCU, MI, Other Educational, or Other Nonprofit

Technical point of contact (POC) including name, mailing address, telephone, and email

Administrative POC including name, mailing address, telephone number, and email address

Award instrument requested: procurement contract (specify type), cooperative agreement or OT.1

Total amount of the proposed effort Place(s) and period(s) of performance Other team member (subcontractors and consultants) information (for each, include Technical POC name, organization, type of organization, mailing address, telephone number, and email address)

Proposal validity period (minimum 120 days) Data Universal Numbering System (DUNS) number2 Taxpayer Identification Number (TIN)3 Commercial and Government Entity (CAGE) code4

1 Information on award instruments can be found at http://www.darpa.mil/work-with-us/contract-management.

2 The DUNS number is used as the Government's contractor identification code for all procurement-related activities. Go to http://fedgov.dnb.com/webform/index.jsp to request a DUNS number (may take at least one business day). For further information regarding this subject, please see www.darpa.mil/work-with-us/additional-baa for further information.

3 See http://www.irs.gov/businesses/small/international/article/0,,id=96696,00.html for information on requesting a TIN. Note, requests may take from 1 business day to 1 month depending on the method (online, fax, mail).

4 A CAGE Code identifies companies doing or wishing to do business with the Federal Government. For further information regarding this subject, please see www.darpa.mil/work-with-us/additional-baa.

http://www.darpa.mil/work-with-us/contract-management http://fedgov.dnb.com/webform/index.jsp http://www.darpa.mil/work-with-us/additional-baa http://www.darpa.mil/work-with-us/additional-baa http://www.irs.gov/businesses/small/international/article/0,,id=96696,00.html

HR001118S0051 SEARCHLIGHT 24

Proposer’s reference number (if any)

ii. Table of Contents

iii. Executive Summary: Provide a synopsis of the proposed project, including answers to the following questions:

What is the proposed work attempting to accomplish or do?

How is it done today, and what are the limitations?

Who or what will be affected and what will be the impact if the work is successful?

How much will it cost, and how long will it take?

The executive summary should include a description of the key technical challenges, a concise review of the technologies proposed to overcome these challenges and achieve the project’s goal, and a clear statement of the novelty and uniqueness of the proposed work.

iv. Innovative Claims and Deliverables: Describe the innovative aspects of the project in the context of existing capabilities and approaches, clearly delineating the uniqueness and benefits of this project in the context of the state of the art, alternative approaches, and other projects from the past and present. Describe how the proposed project is revolutionary and how it significantly rises above the current state of the art.

Describe the deliverables associated with the proposed project and any plans to commercialize the technology, transition it to a customer, or further the work. Discuss the mitigation of any issues related to sustainment of the technology over its entire lifecycle, assuming the technology transition plan is successful.

v. Technical Plan: Outline and address technical challenges inherent in the approach and possible solutions for overcoming potential problems. Demonstrate a deep understanding of the technical challenges and present a credible (even if risky) plan to achieve the project’s goal. Discuss mitigation of technical risk. Provide appropriate measurable milestones (quantitative if possible) at intermediate stages of the project to demonstrate progress, and a plan for achieving the milestones.

vi. Management Plan: Provide a summary of expertise of the proposed team, including any subcontractors/consultants and key personnel who will be executing the work.

Resumes count against the proposal page limit so proposers may wish to include them in Appendix B. Identify a principal investigator (PI) for the project. Provide a clear description of the team’s organization including an organization chart that includes, as applicable, the relationship of team members; unique capabilities of team members; task responsibilities of team members; teaming strategy among the team members; and key personnel with the amount of effort to be expended by each person during the project.

Provide a detailed plan for coordination including explicit guidelines for interaction among collaborators/subcontractors of the proposed project. Include risk management approaches.