olvement in orchestration is typically performed up front in the design process although there may be processes that require intervention or alternate action such as exception or fallout processing. To support the large number of orchestration requests, the orchestration engine is exposed as a reus- service. With this approach, any component of the architecture can request execution of process recipes. Orchestration services are capable of consuming a process recipe and executing against it to completion. The service model maintains consistency and reusability across all orchestration activities and ensures consistent methods, structures, and versioning of the workflow execution environment. Orchestration services expose a common set of APIs to drive consistency across the interaction of ONAP components. To maintain consistency across the platform, orchestration processes inter- act with other platform components or external systems via standard and well-defined APIs. The MSO's primary function is the automation of end-to-end service instance provisioning activities. The MSO is responsible for the instantiation/release, and migration/relocation of VNFs in support of end-to-end service instantiation, operations, and management. The MSO executes well-defined processes to complete its objectives and is typically triggered by the receipt of "service requests" generated by other ONAP components or by order lifecycle management in the BSS layer. The orchestration "recipe" is obtained from the SDC component of the ONAP where all service designs are created and exposed/distributed for consumption. Controllers (infrastructure, network, and application) participate in service instantiation and are the primary players in ongoing service management, for example, control loop actions, ser- vice migration/scaling, service configuration, and service management activities. Each controller instance supports some form of orchestration to manage operations within its scope. Figure 7.4 illustrates the use of orchestration in the two