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 - LCM workflows in Dublin

LCM workflows in SO are composed of activity building blocks. Many of the building blocks correspond to an LCM action towards controller (APPC/SDNC).

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

Frankfurt impacts

To be identified

El Alto improvements

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

Contributions...