MSO High-level System Architecture
See the attached presentation for an explanation of the system architecture of MSO, and its interaction with other ONAP components: MSO High-level Design.
MSO Overview
ONAP orchestration arranges, sequences, and implements tasks based on rules and policies to coordinate the creation, modification, or removal of logical and physical resources in the managed environment. 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 the process steps and components required for execution of a task or service are available when needed.
The MSO's
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 /and release, and subsequent migration /and 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’ service requests generated by other ECOMP ONAP components or by Order by Order Lifecycle Management in Management in the BSS layer. The orchestration “recipe” procedure is obtained from the Service Design and Creation (ASDCSDC) component of the ECOMP Platform ONAP, where all Service Designs service designs are created and exposed/distributed for consumption.
MSO runs autonomously within ONAP.
The orchestration engine is a reusable service. Any component of the architecture can execute process workflows. Orchestration services can consume a process workflow and execute it. The service model maintains consistency and reusability across all orchestration activities and ensures consistent methods, structure and version of the workflow execution environment.
Orchestration processes interact with other platform components or external systems via standard and well-defined APIs.
Controllers (Controllers (Infrastructure, Network and Application) participate in service instantiation and are the primary players in ongoing service management, e.g.; for example, control loop actions, service migration /and scaling, service configuration, and service management activities. Each Controller 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 orchestration1 shows the two major domains that use orchestration: service orchestration, which is embodied in MSO and service control, which is embodied in the Application and Network Controllers. Although the objectives and scope of the domains vary, they both follow a consistent model for the definition and execution of orchestration activities.
Figure 1. Orchestration
Depending on the scope of a network issue,
...
MSO may delegate, or a
...
controller may assume, some of the activities identified
...
in Figure 1. 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
...
do not exist or do not have capacity,
...
MSO will obtain a
...
procedure for instantiation of a new
...
controller under which the requested
...
service can be placed.
ASDC is the module of ECOMP where orchestration In future releases Orchestration process flows are definedwill be defined in the Service Design and Creation subsystem (SDC). These process flows will start with a template that may include common functions such as homing determination, selection of Infrastructure, Network network and Application Controllersapplication controllers, consultation of policies and interrogation of A&AI Active and Available Inventory (AAI) to obtain necessary information needed to guide the process flows. The MSO does not provide any process-based functionality without a recipe workflow for the requested activity regardless of whether that request is a Customer Order or a Service adjustment/ configuration update to an existing service.(in the current release the process flows are designed directly in MSO using BPMN flows).
MSO interrogates AAI MSO will interrogate A&AI to obtain information regarding existing Network and Application Controllers to support a Service Request. A&AI will provide service request. AAI provides the addresses of candidate Controllers controllers that are able to support the Service Requestservice request. The MSO may then interrogate the Controller controller to validate its continued available capacity. The MSO and the Controllers controllers report reference information back to A&AI AAI upon completion of a Service service request to be used in subsequent operations.
8.1
Application, Network, and
Infrastructure ControllerInfrastructure Orchestration
As As previously stated, orchestration is performed throughout the D2 Architecture by various components, primarily the MSO and the Application , and Network and Infrastructure controllersControllers. Each Each will perform orchestration for:
x Service Delivery or Changes to existing Service
x Service Scaling, Optimization, or Migration
x Controller Instantiation
x Capacity Management
- Service delivery or changes to an existing service
- Service scaling, optimization, or migration
- Controller instantiation
- Capacity management
For infrastructure orchestration, ONAP interfaces with the cloud provider's infrastructure control interface. Regardless Regardless of the focus of the orchestration, all recipes will include the need workflows must include steps to update A&AI AAI with configuration information, identifiers and IP Addresses.
Infrastructure
Network Controller Orchestration
Network Controllers are constructed and operate in much the same manner as Application Controllers. New service requests will be associated with an overall procedure for instantiation of that service. MSO obtains compatible Network Controller information from AAI and in turn requests LAN or WAN connectivity to be established and configured. This may be done by requesting the Network Controller to obtain its resource procedure from SDC. It is the responsibility of 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 of which must be included in the procedure 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 MSO to instantiate the service.
Application Controller Orchestration
MSO sends requests to Application Controllers to obtain the application-specific component of the service procedure from SDC and execute the orchestration workflow. MSO ensures that the Application Controller successfully completes its resource configuration as defined by the procedure. As with Network Controllers, all workflows, whether focused on Instantiation, configuration or scaling, will be obtained or originate from SDC. In addition, workflows also report their actions to AAI as well as to MSO.
Note that not all changes in network or service behavior are the result of orchestration. Policies and rules (in the Policy subsystem) inform the controller such that the Controller can enable service behavior changes.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