Versions Compared

Old Version 11

changes.mady.by.user Former user

Saved on

compared with

New Version Current

changes.mady.by.user Hector Anapan-Lavalle

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

A Controller manages the state of a single Resource (Application , Infrastructure, or Network). It executes the Resource's configuration and instantiation, and is the primary player agent in ongoing management, e.g. such as control loop actions, migration, and scaling.  All of these actions involve executing workflows (recipes) obtained from ASDCobtained from Service Design and Creation (SDC). In addition, the Controller reports the status of each workflow execution to both A&AI and MSOthe Active and Available Inventory (AAI) and the Master Service Orchestrator (MSO).

In effect, each Controller instance supports a form of orchestration to manage the operations that are within its scope. This lowThis orchestration is a lower-level of orchestration than the orchestration is done outside by the MSO.

The MSO is responsible for ensuring that the Controller successfully completes its Resource configuration as defined by the recipe.

OpenECOMP uses three distinct  

ONAP uses different Controller types to manage Resources in the execution environment, corresponding to their assigned controlled domain:

  • cloud computing resources (Infrastructure Controller, typically within the cloud layer)
  • network Network configuration (Network Controller)
  • application Application (Application Controller).

Infrastructure Controllers

Infrastructure Controllers typically execute OpenStack requests for the creation of virtual machines (VMs), and load the Virtual Function (VF) software into the new VM container. To do this, the Infrastructure Controller obtains the Virtual Function's Resource recipe from the ASDC. The Resource recipe will define VM sizing, including compute, storage, and memory. 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.
If the Resource 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.
An Infrastructure Controller also has its own recipe, which specifies...?
To create an Infrastructure Resource controller, see ?

Both these controllers are based on an OpenDaylight Controller Framework.

Network Controllers

A Network Controller, such as SDNC, instantiates a Virtual Network Function

...

by carrying out its network configuration workflow and reporting the resulting status (to both

...

AAI and MSO).

...

To create a Network controller, see VNF Onboarding.

Application Controllers

Application Controllers will 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

 

Examples of Network Controllers include those for Transport Virtual Network Functions, infrastructure networking (for instance, leaf, spine, and virtual switches), and Wide-Area-Networks (WANs).

<<DocRef:  the SDN-C User Guide or SDNC API page, if there is one>>

The SDNC network controller in Figure 1 illustrates the core OpenDaylight framework that supports a model driven service abstraction layer (MD-SAL),  api handlers,  operational and configuration trees, and an adapter framework for integrating with controlled devices, virtual functions,  and cloud infrastructure.  Within this framework the ONAP Service Logic Interpreter (SLI) addition provides an extensible scripting language for expressing service logic through a Directed Graph (DG)  builder based on Node-Red.   The SLI is extended by adding Java classes that can be called as a node in a DG to support frequent complex operations.

Image Added

Figure 1. SDNC Network Controller

<<TODO Find Reference and example DG and SLI extension node in a Gerrit Project>>

Application Controllers

Application controllers, such as APPC,  receive orchestrated requests from the MSO, which obtains application-specific components and attributes from SDC.  The MSO continues to be responsible for ensuring that the Application Controller successfully completes its Resource configuration as defined by the

...

workflow.

...

Note that not all changes in network or service behavior are the result of orchestration.

...

To create an Application controller, see ? Policies and rules (in the Policy subsystem) inform the controller such that the Controller can enable service behavior changes.

ONAP includes a generic Application Controller (APPC, formerly called APP-C) that receives commands from ONAP components, such as MSO, DCAE, or the Portal, and uses these commands to manage the life cycle of Services, Resources (virtual applications and Virtual Network Functions), and their components. The Application Controller is based on the same OpenDaylight Framework with SLI additions.   The Application Controller project provides SLI node types, adapters, and API handling logic required for the life cycle management of complex, distributed services composed of many VNF types and instances.

Documentation:

NOTE: For instructions on how to build and run an ONAP Component (APP-C is taken as an example) locally, please refer to this documentation.