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 orchestration is a lower-level of orchestration than the orchestration done by the MSO. 

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

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

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). 

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.


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.  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.


  • No labels

13 Comments

  1. Dhananjay Pavgi

    Hi There, Whether SDN-C network controller would work with any framework of SDC controller such as OpenContrail, Juniper Contrail. Or it's tightly bound with OpenDayLight.

  2. Dan Timoney

    The SDN-C network controller is based on OpenDaylight.  It is certainly possible to interact with other controllers through device adaptors, but currently the only native SDN controller that the SDN-C network controller runs within is OpenDaylight.

    1. Dhananjay Pavgi

      Thanks, Dan.What are device adaptors? Are they different from Network Adaptors? 

  3. Dan Timoney

    Sorry, I meant to say network adaptor, not device adaptor.


  4. Kite Bo

    How many network controller in openEcomp now ? Can this network controller control WAN directly ?

  5. Brian Freeman

    The ODL controller has netconf and bgpcep adaptors that can control WAN directly. We haven't included the matching SLI nodes for those adaptors at this time but that is clearly possible. Depending on the WAN devices a custom interface may also be required (e.g., ssh) which would be vendor specific. We have also interfaced to commercial EMS's via REST API's from the SLI.  The additional flavors/applications of SDN in ONAP are a good topic for discussion since their northbound and southbound will vary. The TransportPCE project in ODL is one such example. What type of WAN control are you thinking about ?

  6. Jacopo Pianigiani

    So , in order to integrate another controller (e.g. OpenContrail) what are the dependencies ? What are the integration points for which to build an adapter ?

  7. Randa Maher

    For APPC documentation, please refer to APPC documentation on readthedocs: http://onap.readthedocs.io/en/latest/index.html

  8. Ullas Kumar K Y

    Can APPC interface directly with 3rd party Service Orchestrators other than the ONAP MSO? (assuming that the interfacing Orchestrator complies with REST API's or Message Bus exposed). If it can , is there any additional security requirements?  

  9. Randa Maher

    The preferred method to communicate to APPC is over the message bus (DMaaP). APPC provides an APPC Client library and as long as 3rd pty SO uses APPC client library to formulate request, then it should be transparent to APPC. You can read up on the APPC client library and APIs supporting on readthedocs: http://onap.readthedocs.io/en/latest/guides/onap-developer/developing/index.html#application-controller. Communicate via DMaaP would be done over secure topics.

  10. Sunny Gupta

    I on-boarded the VNF successfully. Now I was trying to figure out how to push VNF configuration through APP-C using Netconf. I uploaded VNF specific yang and xml configuration templates during design phase in SDC, but couldn’t find how to access those objects using APP-C Restconf.

    There is one link ( http://onap.readthedocs.io/en/latest/submodules/appc.git/docs/APPC%20CDT%20Guide/APPC%20CDT%20Guide.html ) that talks about  APPC Configuration design tool which I think is part of Beijing release only and my setup is on Amsterdam release.

    Any help available on this ?

    1. Randa Maher

      Sunny, CDT is only available with Beijing. I would strongly recommend upgrading to Beijing release. We should have release dockers in Nexus by next week. Also, you can refer to our wiki pages for valuable information on testing and usage of CDT. APPC ONAP Testing Notes. There is a good recording here that shows how we created the templates needed for ConfigScaleOut of vLB: Creating the vLoadBalancer in the CDT

  11. Rebecca Lantz

    I don't see VFC listed as a Controller here, and in fact can't find details to it in the Architecture portion of the wiki pages. My question is this: Must a VNF have one and only one Controller?   Specifically, what if a VNF wants or needs to use a S-VNFM for LCM (implying need for VFC), but would also like to make use of DCAE and APPC for application specific closed loop automation?   Or just general overall management?  Is this possible?