Objectives

Assumptions:

1. Operator has already deployed ETSI SOL003 compliant VNF Manager(s)
2. Operator has already deployed ETSI SOL005 compliant NFVO(s)
3. Operator has existing Service Assurance tools that VNF(s) interact with
4. Operator is currently using proprietary mechanisms to configure NFs
5. Operator has used above mechanisms to deploy SOL001/SOL004 compliant VNFs
6. Operator has multiple VIMs; with different HW capabilities and configurations
7. Operator desires to integrate ONAP into the existing environment

Objectives

• Examine orchestration scenarios in order to determine if new architectural requirements are necessary
• Develop recommendations for composition of the ONAP Service DM (How does the ETSI NFV SOL001 Network Service Descriptor supported?)
• Develop recommendations for interfaces between the orchestration elements (OSS, SO, VF-C, VNFM, NFVO)
• Develop recommendations for how ONAP controllers work with external orchestration elements (NFVO, VNFM, EMS)
• Develop recommendations for how external Service Assurance interacts with DCAE and Policy
• Develop recommendations on breaking ONAP into more modular consumable pieces (Margaret)

To Do's

•  Recommendation on whether an ONAP should support an E2E Service  that is composed of xNFs that are orchestrated by separate orchestrators (SO,  SO + external VNFM, VF-C, external NFVO) for next Arch meeting (Nov 13)
•   Mapping of SOL005 APIs to ONAP NBI
•  Develop scenarios with stories about how ONAP could be used in near term brownfield  legacy environment Fernando Oliveira
•  Develop scenarios with stories about how a legacy environment could migrate off of a brownfield legacy environment towards a ONAP native model Fernando Oliveira
•  Describe how ONAP DCAE could be integrated with legacy Service Assurance platform Fernando Oliveira
•  Describe how legacy inventory system would interact with ONAP A&AI
•  Develop scenarios for how Application Configuration could be supported with enhanced SOL001 VNF-D using an external SOL003 compliant VNF Manager Fernando Oliveira 

Implications/Requirements

1. ONAP needs to ingest and save (without modification) a SOL004 CSAR package for later consumption by a SOL003 compliant VNF Manager (VNFSDK, SDC)
   1.  Original CSAR contents need to be preserved since some VNF Managers validate the manifest signatures of each file in the CSAR
2. ONAP needs to ingest and interpret a SOL001 compliant VNF Descriptor in order to design an ONAP Service (VNFSDK, SDC)
3. ONAP needs to understand resource requirements in the VNF-D for each deployment and scaling level (SO, A&AI, OOF)
   1. ONAP needs a way to ingest or create a VIM tenant/project space (SO, SOL003 Adapter, Multi-Cloud/VIM)
   2. ONAP needs to inventory  the VIM tenant/project resources and capacity (A&AI, Multi-Cloud/VIM)
   3. ONAP needs to confirm that the VIM resources (vCPU, RAM, Storage, Network, EPA (SR-IOV, GPU, Pinnned CPU, Locked RAM, ..), ...) necessary for the deployment or scale operation are available (SO, A&AI, OOF)
   4. Such resources should be reserved if the VIM has that capability (OOF, Multi-Cloud)
4. ONAP needs to have a SOL003 compliant SBI (SOL003 Adapter, APP-C, VF-C, GNF-C, SO))
5. ONAP needs a mechanism for specifying that a VNF instance should be runtime managed by a particular VNFM type (design time)  and instance (run time) (SDC, OOF, SO)
   1. This likely also applies to other external controllers
6. ONAP needs to have a way to inventory a VNF that was deployed using an external VNFM and which instance of the VNFM (A&AI, SO, SOL003 Adapter, VF-C) 

Contributions...

Recording of call 11/12/2018: double_click_to_convert_01.zoom

Recording of call Dec 17, 2018: [Onap-arc] Orchestration Scenarios and implications on modeling weekly-20181217 1404-1.mp4

VZDeploymentOptionLegacy.pptx

Updated with Application configuration and Hierarchical Service (VNF + NS): VZDeploymentOptionLegacy.pptx

https://docbox.etsi.org/ISG/NFV/Open/Other/Tutorials/Tutorials-201810_SDN_NFV_World_Congress-The_Haque/ETSI_NFV_Layer123_VNF%20Configuration-v2_RX15009.pdf

Recording of Dec 20, 2018 call: [Onap-arc] Orchestration Scenarios Discussion on ETSI VNFD ConfigurableProperties-20181220 1806-1.mp4

OrchestrationScenariosDDF.pptx

ONAP_GNF_ControllersSOL003.pptx

ApplicationConfigElAlto.pdf

• 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

Image Added

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

Image Added

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

Image Added

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.

Image Added

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.

--

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:

• creation of a placeholder in the userParams section of the SO request, along with acceptable values for it

  • proposal: LCM_API as placeholder. APPC and GNFC as values

    Code Block
    "userParams": [ { "LCM_API": "APPC" or "GNFC" } ]

    
    

    • This will impact the WorkflowAction.java class that would need to set the appropriate variable in the BPMN context; see here for homing example: https://github.com/onap/so/blob/master/bpmn/so-bpmn-tasks/src/main/java/org/onap/so/bpmn/infrastructure/workflow/tasks/WorkflowAction.java#L332-L345
• An LCM BPMN with a conditional block based on the value able to build and trigger the request on the right system, similar as https://github.com/onap/so/blob/master/bpmn/so-bpmn-tasks/src/main/java/org/onap/so/bpmn/buildingblock/HomingV2.java and https://github.com/onap/so/blob/master/bpmn/so-bpmn-building-blocks/src/main/resources/subprocess/BuildingBlock/HomingBB.bpmn
• A well know list of potential LCM action provided by GNFC
• A client to GNFC (already done)

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

Image Added

El Alto improvements

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

Contributions...