Orchestration can be viewed as the definition and execution of workflows or processes to manage the completion of a task. In OpenECOMP, orchestration automates the activities, tasks, rules and policies needed for on-demand creation, modification, or removal of network, application or infrastructure services and resources. The Master Service Orchestrator (MSO) manages orchestration at the top level and facilitates additional orchestration that takes place within underlying controllers. It also marshals data between the various controllers so that they have all of the process steps and the necessary components are available to them to complete the execution of a task or service.
The MSO runs autonomously within OpenECOMP. its job is to manage orchestration at the top level and to facilitate the orchestration that takes place within the underlying controllers and marshal data between the Controllers such that they have the “process steps” and all the “ingredients” to complete the execution of their respective recipes.
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.
Depending on the scope of a network issue, the MSO may delegate, or a Controller may assume, some of the activities identified above. Although the primary orchestrator is called “Master Service Orchestrator (MSO), its job is to manage orchestration at the top level and to facilitate the orchestration that takes place within the underlying controllers and marshal data between the Controllers such that they have the “process steps” and all the “ingredients” to complete the execution of their respective recipes. For new services, this may involve determination of service placement and identification of existing controllers that meet the Service Request parameters and have the required capacity. If existing controllers (Infrastructure, Network or Application) do not exist or do not have capacity, the MSO will obtain a recipe for instantiation of a new Controller under which the requested Service can be placed.
ASDC is the module of ECOMP where orchestration process flows are defined. These process flows will start with a template that may include common functions such as homing determination, selection of Infrastructure, Network and Application Controllers, consultation of policies and interrogation of A&AI to obtain necessary information to guide the process flows. The MSO does not provide any process-based functionality without a recipe for the requested activity regardless of whether that request is a Customer Order or a Service adjustment/ configuration update to an existing service.
MSO will interrogate A&AI to obtain information regarding existing Network and Application Controllers to support a Service Request. A&AI will provide the addresses of candidate Controllers that are able to support the Service Request. The MSO may then interrogate the Controller to validate its continued available capacity. The MSO and the Controllers report reference information back to A&AI upon completion of a Service request to be used in subsequent operations.
8.1 Application, Network and Infrastructure Controller Orchestration
As previously stated, orchestration is performed throughout the D2 Architecture by various components, primarily the MSO and the Application, Network and Infrastructure controllers. Each will perform orchestration for:
- Service Delivery or Changes to existing Service
- Service Scaling, Optimization, or Migration
- Controller Instantiation
- Capacity Management
Regardless of the focus of the orchestration, all recipes will include the need to update A&AI with configuration information, identifiers and IP Addresses.
Infrastructure Controller Orchestration
Like the MSO, Controllers will obtain their orchestration process and payload (templates/ models) from Service Design & Creation (ASDC). For Service instantiation, the MSO maintains overall end-to-end responsibility for ensuring that a request is completed. As part of that responsibility, the MSO
will select the appropriate controllers (Infrastructure, Network, and Application) to carry out the request. Because a Service Request is often comprised of one or more Resources, the MSO will request the appropriate Controllers to obtain the recipe for the instantiation of a Resource within the scope of the requested Controller. After service placement is determined, the MSO may request the creation of a Virtual Machine (VM) at one or more locations depending on the breadth of the service being instantiated and whether an existing instance of the requested service can be used. If new VM resources are required, the MSO will place the request to the Infrastructure Controller for the specific AIC location. Upon receipt of the request, the Infrastructure Controller may obtain its Resource Recipe from ASDC. The Infrastructure Controller will then begin orchestrating the request. For Infrastructure Controllers, this typically involves execution of OpenStack requests for the creation of virtual machines and for the loading of the Virtual Function (VF) software into the new VM container. The Resource recipe will define VM sizing, including compute, storage and memory. If the Resource Level Recipe requires multiple VMs, the MSO will repeat the process, requesting each Infrastructure Controller to spin up one or more VMs and load the appropriate VFs, again driven by the Resource Recipe of the Infrastructure Controller. When the Infrastructure Controller completes the request, it will pass the virtual resource identifier and access (IP) information back to the MSO to provide to the Network and Application controllers. Along the entire process, the MSO may write identifier information to A&AI for inventory tracking.
Network Controller Orchestration
Network Controllers are constructed and operate in much the same manner as Application and Infrastructure Controllers. New Service requests will be associated with an overall recipe for instantiation of that Service. The MSO will obtain compatible Network Controller information from A&AI and will in turn request LAN or WAN connectivity and configuration to be performed. This may be done by requesting the Network Controller to obtain its resource recipe from ASDC. It is the responsibility of the MSO to request (virtual) network connectivity between the components and to ensure that the selected Network Controller successfully completes the Network configuration workflow. A Service may have LAN, WAN and Access requirements, each ofwhich will be included in the recipe and configured to meet the instance specific customer or service requirements at each level. Physical Access might need to be provisioned in the legacy provisioning systems prior to requesting the MSO to instantiate the service.
Application Control Orchestration
Application Controllers will also be requested by the MSO to obtain the Application Specific component of the Service Recipe from ASDC and execute the orchestration workflow. The MSO continues to be responsible for ensuring that the Application Controller successfully completes its Resource configuration as defined by the recipe. As with Infrastructure and Network Controllers, all workflows, whether focused on Instantiation, configuration or scaling, will be obtained or originate from ASDC. In addition, workflows also will report their actions to A&AI as well as to MSO.
Note that not all changes in network or service behavior are the result of orchestration. For example, application Virtual Functions can change network behavior by changing rules or policies associated with Controller activities. These policy changes can dynamically enable service behavior changes.