O and ONAP architectures. The Network Operating System ONAP can be considered as a very full-featured, enhanced generic VNF manager as described by MANO NFV MANO architectural options (see Figure 7.3). In addition, ONAP subsumes the traditional FCAPS functionality as supported by EMSs in the MANO reference architecture. This is critical to implementing analytic-driven closed-loop auto- mation across the infrastructure and VNFs, analyzing cross dependencies and responding to the root cause of problems as quickly as possible. To successfully implement ONAP, the Ve-Vnfm- vnf interface (as well as Nf-Vi) is critical. It is expected that the Ve-Vnfm-vnf interface is stan- dard interface defined by ETSI. ONAP's approach is to document detailed specifications for such interface(s) to collect rich real-time data in a standard format from a variety of VNFs and quickly integrate with ONAP without long custom development work. 7.2 MASTER SERVICES ORCHESTRATOR In general, orchestration can be viewed as the definition and execution of workflows or processes to manage the completion of a task. The ability to graphically design and modify a workflow process is the key differentiator between an orchestrated process and a standard compiled set of procedural code. Orchestration provides a "template" approach, allowing for adaptability and improved time to market; it provides ease of definition and change without the need for a development engagement. As such, it is a primary driver of flexibility in the architecture. Interoperating with policy, the com- bination provides a basis for the definition of a flexible process that can be guided by business and technical policies and driven by process designers. Orchestration exists throughout the ONAP architecture and should not be limited to the con- straints implied by the term "workflow," as it typically implies some degree of human intervention. Orchestration in automated network clouds will not involve human intervention/decision/guidance in the vast majority of cases. The human inv