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.

Background -

SO workflows in Dublin

LCM workflows in SO are composed of activity building blocks. Many 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, plus a variation that moves out some of the functionality to a new LCM API Gateway service.

• TODO: More options? Pros and cons per option

Image Removed

Image Removed

Frankfurt impacts

To be identified. 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.

Image Added

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

Other options

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.

Image Added

El Alto improvements

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

Contributions...