Kickoff Materials/Background

Meeting Information



  • APs status (in line in the page)
  • Finalize Frankfurt Architecture and reccomendations
  • Ask for target architecture consensus 
  • Reschedule follow up in ONAP Architecture subcommittee
  • Follow up on SOL002 adapter

Discussion on ARCH Subcommittee jira Stories: 

ONAPARC-470 - Getting issue details... STATUS



  • Enable use of CDS for self-service LCM operations currently supported by APPC and SDNC
  • Identify target architecture for LCM API consolidation across different controllers: APPC, SDNC including CDS

  • Identify migration path need

  • Identify ONAP recommendations in case of

    • Supporting PNFs for applicable LCM operations
    • How and where to describe standard actions/operations including input parameters in payload
    • Adding a new LCM operation

    • A new UC/sw contribution with current LCM operations

  • Frankfurt way forward

To Do's

  • Identify target architecture and recommended evolution for the Frankfurt (R6) release

  • Establish LCM API principles and recommendations

  • Conclude migration path need for APPC/SDNC

  •  Identify component candidates for CCSDK

Target Architecture

  • SO/Policy communicate to GnfC using grpc via Self Service API.

gNFC can provide  1) direct connection to node via Chef/Netconf/Ansible adapters

                               2) direct connection to VIMs

                               2) adapters for external systems (i.e. EM or 3PP VNFM). SOL003 and SOL002 adapters have been discussed

                               3) can provide interworking with other internal components 

Takamune ChoDan Timoney : comments are welcome to reach a consensus across PTL controllers

Background - SO workflows in Dublin

SO supports service and resource workflows built from BPMN building blocks. Workflows are used e g for instantiation, scaling and change management. Some of the building blocks correspond to an LCM action towards controller (APPC/SDNC). Other building blocks send requests to AAI, GR-API (SDNC), VNF adapter or SOL-003 adapter.

Example below shows a change management activity building block using APPC client. In Dublin CDS is not used by SO except for configAssign and configDeploy. Another limitation is that PNFs are not supported by the generic building block framework and so far need to use custom BPMN workflows.

Frankfurt Step

Current best thinking for Frankfurt is to support multiple controller APIs by branching within SO based information in the distributed models (TOSCA/CSAR).

A more detailed diagram of this solution is shown below. The Java code called from BPMN would be extended to select either current path for APPC/SDNC or a CDS path. For PNFs there is a need to also update the building block framework to fully support the PNF resource type and then create either shared VNF/PNF or dedicated PNF building blocks.

To follow up: Request to have diagram showing also the SOL-003 adapter and how it relates to the other components.

SO impacts in Frankfurt

How to implement the selection of the controller in SO in a model driven approach.

Alexis de TalhouëtSeshu Kumar Mudiganti  to provide an input for the next meeting.


Following the same pattern used to select the homing solution, SO could implement the selection of the controller LCM endpoint.

This would required the following:

(Oskar Malm) The approach outlined above requires run-time input from the operator. I would like to propose a bit different high-level principles for further discussion:

  • The resource/service designer may attach CDS blueprint(s) to resource or service (= resource customization). This indicates that blueprint shall be used for self-service LCM actions. TBD: Blueprint presence enough as selector, or need for additional model data/properties. Level of granularity - which actions are handled by each blueprint?
  • The designer will not indicate specific controller to be used
  • At run-time the SO building block will use only model data from design-time to conclude whether CDS path and API shall be used. (Until now, only SDNC deploys the blueprint processor mS. If in the future multiple personas or instances would deploy the blueprint processor, additional logic must be defined to select which one to use.)

LCM API principles and recommendations in Frankfurt

A convergency between API  controllers should start in Frankfurt.

In case a new operation need to be introduce in the NBI controller, it is reccomended the gRPC SSAPI

Other possible architecture option discussed for Frankfurt

A number of other architectural options exist.

Example below would move selection and use of controller API out of main SO module. Feedback is that option A is better first step for Frankfurt. 

If SO cannot implement option A in Frankfurt,  other implementation options, as option B, can be considered.

El Alto improvements

  • External SOL003 Adapter as an Independent deployable component  (in relation to VNF LCM and Orchestration track)


  • No labels


  1. Is LCM API going to be available to external systems similar to Ext API capability of ONAP?

    We are looking for capabilities where ONAP can perform LCM on external VNFs created on external VIM by a 3rd party orchestrator

    1. Which LCM actions are you looking to perform?  Samsung (Katsia Kazak)has proposed adding a SOL002 interface to the GNF-C which would support VNF configuration and event (indications) redirection into DCAE.   The northbound LCM API is likely to be ONAP specific and not be directly accessible externally.

    2. Syed, we don't put focus on delivering such functionality to ONAP for now. Although most probably it will be possible to use it with some tweaks on ONAP side, as our proposal comes from PoC that was actually performing your use-case. If you're interested and you will be visiting DDF - come to my presentation 'VNF Application Configuration in ONAP' on Wednesday 3.00 PM in E8 (smile) I won't be able to give you full details, but the general idea will be presented by me.

  2. Katsia Kazak thanks for the info. I could not attend DDF, do you have a recording of the session that I can watch?

    I want to understand how we can make ONAP available in a brownfield scenario where there are existing VNFs created on another NFVi