Orchestration is the function defined via a process specification that is executed by an orchestrator component which automates sequences of activities, tasks, rules and policies needed for on-demand creation, modification or removal of network, application or infrastructure services and resources. The MSO provides orchestration at a very high level, with an end-to-end view of the infrastructure, network, and application scopes.
The Master Service Orchestrator’s (MSO’s) primary function is the automation of end-to-end service instance provisioning activities. MSO provides the BSS systems an interface to orchestrate delivery of D2 services.
BSS End to End Orchestration will decompose the customer request in to D2 and non-D2 services based on rules from the product catalog. The BSS End to End Orchestration triggers the MSO to initiate ECOMP activity, and the MSO manages the provisioning/network activity by interacting with Controllers as required. The MSO sends the business level status back to the BSS Orchestration. The BSS Orchestration does not maintain provisioning logic nor manage provisioning processes.
The MSO runs autonomously within OpenECOMP. It automates activities, tasks, rules and policies needed for on-demand creation, modification or removal of network, application or infrastructure services.
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 adaptability and improved time-to-market due to the 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 combination 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 D2 architecture and should not be limited to the constraints implied by the term “workflow” as it typically implies some degree of human intervention. Orchestration in D2 will not involve human intervention/decision/ guidance in the vast majority of cases. The human involvement in orchestration is typically performed up front in the design process although there may be processes that will require intervention or alternate action such as exception or fallout processing.To support the large number of Orchestration requests, the orchestration engine will be exposed as a reusable service. With this approach, any component of the architecture can execute process recipes. Orchestration Services will be 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, structure and version of the workflow execution environment.
Orchestration Services will expose a common set of APIs to drive consistency across the interaction of ECOMP components. To maintain consistency across the platform, orchestration processes will interact with other platform components or external systems via standard and well-defined APIs.
The Master Service Orchestrator’s (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 overall ECOMP 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 ECOMP components or by Order Lifecycle Management in the BSS layer. The orchestration “recipe” is obtained from the Service
Design and Creation (ASDC) component of the ECOMP Platform 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, e.g., control loop actions, service migration/scaling, service configuration, and service management activities. Each Controller instance supports some form of orchestration to manage operations within its scope.
Figure 10 illustrates the use of Orchestration in the two main areas: Service Orchestration embodied in the Master Service Orchestrator and Service Control embodied in the Infrastructure, Application and Network Controllers. It illustrates the two major domains of D2 that employ orchestration. Although the objectives and scope of the domains vary, they both follow a consistent model for the definition and execution of orchestration activities.