testing purposes, to complex service emulations orchestrated for trouble- shooting purposes. In both cases, DCAE provides the ability to collect the results of health checks and tests that are conducted. These checks and tests could be done on an ongoing basis, scheduled or conducted on demand. f. Other-the applications that are listed above are by no means exhaustive and the open architecture of DCAE will lend itself to integration of application capabilities over time from various sources and providers. POLICY ENGINE ONAP is responsible for the design, creation, deployment, and lifecycle management of virtual- ized network functions (VNFs). One of its goals is to do this in a flexible, dynamic, metadata, and policy-driven manner-letting users dynamically control ONAP's behavior without changing Building the Network of the Future the system software. ONAP's policy component allows users to express, interpret, and evaluate policies, and then pass them on to other ONAP components or network elements for enforcement. ONAP policies capture the service provider's network operational, security, and management intelligence-including proprietary domain knowledge related to how a service provider manages networks and services. One of ONAP's goals is to automate the life cycle of network-based services, including fault, performance, and service management, via control loops. Control loops define how VMs, VNFs, and service impairments are detected, isolated, and resolved, either automatically (closed-loop control) or through manual resolutions. As an example, a control loop policy might specify whether a VM is down or not responding (the signature it is exhibiting), then the VM needs to be restarted (the response required). The signatures and responses that define a control loop are specified as policies within ONAP; these policies capture the operational domain knowledge regarding the automation that is to be enabled. Policies oversee various aspects of ONAP's behavior, include the following: 1. Service design-for example