ONAP Usecase El Alto Usecase1 ONAP as Third

ONAP Usecase El Alto

Usecase#1: ONAP as “Third Party” Operational Domain Manager • Interaction Flow • Definition • • • A standards-based approach that supports 3 rd party service management 3 rd party Catalog import onto SDC -> publish Catalog -> submit an O 2 A order -> Fulfil the order • Changes foreseen • NBN Fixed Broadband Service, • Managed Network Service • SDC – Import 3 rd party catalog, Publish catalog • Telco peers • SO work for Order Activation • Multiple Cloud Service Providers • A&AI – add info on 3 rd party domain inventory • Etc… • Enhancements to Ext APIs ONAP provides Operations Domain Management (ODM) and other complementary capabilities to ensure full automation of the E 2 E lifecycle management of the service • Services are exposed and consumable via Network as a Service (Naa. S) Consistent way of consuming 3 rd party services from Telstra • LCM and assurance events are triggered by the remediation response are executed. • Substitutes multiple handovers between parties/teams and applications to enable zero touch automation 3 rd party service, and • The service life cycle management action can trigger for: • CM: change management (capacity increase to meet scaling demands); • IM: incident management (problem identification and fix); and • VM: version/config. management (VNFs’ adaptation to topology/config changes during run time of the service) Remediation actions are executed automatically using ONAP as ODM Network as a Service (Naa. S) ODM (ONAP) Beneficiary: 3 rd party domains 3 rd Party Domain Ext API - Open APIs to be used/enhanced : Service Catalog – Catolog updates Service Inventory – AAI updates

Usecase#1: Flow Diagram for 3 rd Party Catalog Sync and Order Activation This flow diagram depicts external catalog sync into SDC followed by order request from BSS ONAP Ext API ONAP SDC ONAP SO ONAP AAI 3 rd Party Domain Invoke Open API 633 Service Catalog INTERLUDE Update SDC Catalog Update AAI Get Service Catalog Details LEGATO Submit Order – Open API 641 LEGATO Update SO catalog Notify Update Success INTERLUDE Submit Order Invoke 3 rd Party Ordering API INTERLUDE Decompose Service Send back to Ext API

Usecase#1 a: Flow Diagram for SDC Catalog Import (In-Progress) This flow diagram displays the activities for the importing an external service catalog into ONAP 3 rd Party Domain / 2 nd ONAP instance Open API 633 Service Catalog POST nbi/api/ v 3/service. Specification Cassandra SDC Ext API Update SDC Catalog POST sdc/v 2/catalog/services Invoke onboarding API SDC Distribution client Update SDC DB Invoke sdc-dao package to Parse the CSAR and insert data in Cassandra schema Request body – ONAP compatible CSAR Retrieve service details From the database Invoke Distribution Client Reuse distribution function to publish the service to registered ONAP components

I m p o r t e x t e r n a l SDC • Introduce POST function to SDC on-boarding functionality • Reuse sdc-dao to update the Cassandra database and store the new service in SDC catalog • Reuse SDC distribution functionality to distribute the new service to registered ONAP components (no change ) • Feedback from Ofir - Create ONAP compatible CSAR input to be consumed by the POST (to be analysed). The UUID creation functionality of SDC needs to be maintained, so that UUID is created on the fly in the same manner as today A&AI – add info on 3 rd party domain inventory • This feature is already available in Dublin as part of heatbridge functionality. It has been moved to SO Ext APIs • Introduce POST for TMF API 633 – Service Catalog API P

Usecase#2: ONAP as “VNF” operational Domain Manager • Definition • Interaction Flow • A standards-based approach that supports VNF on-boarding and VNF life cycle management. • Domains implement Open API (TMF 640, 653/656) and uses ONAP as the ODM where applicable • ONAP provides Operations Domain Management (ODM), where applicable, and other complementary capabilities to ensure full automation of the E 2 E lifecycle management, including onboarding of the VNF • ODM exposes a service via Naa. S and interacts with other domains, e. g. NFVi which contains the VNF repositories • The VNF life cycle management action VNF can be triggered for: • CM: change management (capacity increase to meet scaling demands); • Services are exposed and consumable via Network as a Service (Naa. S) • IM: incident management (problem identification and fix); and • TMF APIs are implemented southbound of the service towards the responsible domains • VM: version/config. management (VNFs’ adaptation to topology/config changes during run time of the service) • LCM and assurance events are triggered by the VNF services, and remediation actions are applied at the resource level e. g. NFVi • Substitutes multiple handovers between parties/teams and applications to enable zero touch automation • Constituent VNFs of a service are onboarded through an automated process, and then managing the VNF service life cycle • Remediation actions are executed automatically by the responsible domain Network as a Service (Naa. S) ODM (ONAP) Beneficiary: NFVi Orchestrator (ECM) Open APIs: 640: change and version management 653/656: incident management “X” VNF Domain (e. g. v. FW, v. CPE) Cloud Platforms, e. g. Open. Stack, VMWare, KVM… NFVi Domain

P o C • Scope • Po. C is simplified to explore VNF lifecycle management and assurance in an automated fashion in a cross domain scenario using ONAP • We have 3 VNFs, 1 in each domain. And they are in three different domain inventories. Use of ONAP AAI • VNFs interact with each other (ping/pong VNFs) in cross domain scenario. Use of ONAP SO and External APIs • VNFs have been designed (use SDC) to have LCM and assurance events notification ability (use of ONAP DCAE) • VNFs are self-managed and self-healing to predefined change, incident, version management scenarios – Network as a Service (Naa. S) C o n c e p ODM 1 (ONAP) VNF 1 ODM 2 (NONONAP) VNF 2 Inventory #2 A&AI #1 ODM 1 (ONAP) representing as Composite Service Domain VNF 3 #3 has reference to #1 and #2 A&AI #1

Requirements in ONAP modules • A&AI cross domain service and resource topology needs to be enhanced • There is need for persistence of resource topology details in A&AI • Today VNF details from VIM (openstack) are not persisted in AAI, when a VM in created for a VNF. This info is needed by monitoring systems for service assurance • Generic API workload functionality is taking care of updating AAI with resource topology details. Need to verify if this is already available in Dublin • Ext APIs • 633 – Introduce POST in Ext API Service Catalog to add capability to import catalogs into ONAP • 640 - To support Naa. S, Ext API will need to support 640 Service Activation API – 641 can take care of the Service Order creation for an existing service but to automate a service creation we need 640 • 653 and 656 – for events coming from 3 rd party domain Naa. S will need to trigger Service Problem and Service Test Management APIs. So these should be exposed from Ext API NBI

Requirements continued… • Requirements continued… • DCAE blue print dynamic creation is needed for policy generation and usage in CLAMP for closed loop assurance • This requirement is already part of El Alto Closed Loop Use Cases. We can contribute to that for our use case realisation • SO needs (BPMN) flows to trigger service test API and service problem mgmt. API • SDC • Service catalog interaction between 3 rd party Domain and SO i. e. ONAP, • Need PUT/POST capability in service catalog API – so that 3 rd party can share catalog details • SO will send request to DO using open API.