Objectives

• 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 Cho , Dan 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ët , Seshu Kumar Mudiganti  to provide an input for the next meeting

TO BE ADDED 

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)
  
  

Contributions...