• Created by Unknown User (fay), last modified by Unknown User (rnnavarro) on Jan 18, 2017

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 33 Next »

A Controller manages the state of a single Resource (Application or Network). It executes the Resource's configuration and instantiation, and is the primary agent in ongoing management, such as control loop actions, migration, and scaling.  All of these actions involve executing workflows obtained from Service Design and Creation (SDC). In addition, the Controller reports the status of each workflow execution to both the 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 low-level orchestration is done outside the MSO. The MSO is responsible for ensuring that the Controller successfully completes its Resource configuration as defined by the workflow.

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

  • Network configuration (Network Controller)
  • Application (Application Controller).

Network Controllers

A Network Controller instantiates a Virtual Network Function by carrying out its network configuration workflow and reporting the resulting status (to both AAI and MSO). 

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

<<TODO: point to a Network Controller example, or information on how to create one, or point to the SDN-C User Guide or API Guide>>

Application Controllers

The MSO sends requests to the Application Controllers to obtain the application-specific component of the Service workflow from SDC and to 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 workflow.

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.

OpenECOMP includes a generic Application Controller (APP-C, sometimes called APPC) that receives commands from OpenECOMP 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. See the OpenECOMP Application Controller User Guide and the <<DocRef: Application Controller (APP-C) API Guide>>.

  • No labels