Page Comparison

Project materials can be found found here

Name of Use Case: Third Party Operational Domain Manager

Participants : Telstra (Use Case Owner)

Endorsing Service Providers :

Vodafone

Verizon (including contribution towards ETSI SOL alignment)

Description:

• A standards-based approach that supports third party service management
• Fixed Broadband Access Service from third party
• Managed Network Service
• Telco peers
• Multiple Cloud Service Providers
Etc…allows a service provider to have a network automation platform for composite or white labelled services managed by specific/ Third Party “ domain managers
• ONAP provides Operations Domain Management (ODM) and other complementary capabilities to ensure full automation of the E2E lifecycle management of the service via federation
• Services are exposed and consumable consumed via Network as a Service (NaaS) which w”hich is an abstraction layer above the operational domains and exposes the services to BSS
• Consistent way of consuming 3rd party services from Service ProvidersLCM and assurance events are triggered by the 3rd party service, and remediation response are executed.for service providers like Telstra
• ONAP will facilitate service operations value chain for third party domain via federation
• Substitutes multiple handovers between parties/teams and applications to enable zero touch automation

Image RemovedImage Added

BUSINESS DRIVER 

...

Executive Summary - This use case will provide ONAP capability to be operational domain manager for third party services. Service providers will be able to use ONAP to provide end to end automation for composite or white labelled services which could be provided and managed by third parties. This use case will provide ONAP capability to support federated catalog and orchestrationIn case of Tier 1 / Brownfield operators, it’s likely that ONAP might need to interface with existing automation solutions for specific domains.

Business Impact - The use case provides a generic ability capability in ONAP for seamlessly on-boarding partner domain catalog which can be leveraged by service providers using ONAPboarding service specifications from partner (or specific ) domain catalog. Lack of this capability leads to manual creation of partner service catalogs services in ONAP which is time consuming and dependent on human interventionerror prone. With introduction of this capability, the partner catalogs will be available for placing orders for Partner Domain services very quickly. The future ONAP will be able to consume domain specific service definitions via Open APIs and publish the same to run time components. Next phase of this use case also plans to look at enhancing will extend the operational domain manager capabilities for life cycle management and also managing assurance events  triggered by the third party service and execute remediation responseto support complete entire service operations value chain for “Third Party” or Domain specific services via federation.

Business Markets - Following can be potential candidates for Third Party (or Partner) Domains which can be managed by ONAP

...

.

• Fixed Broadband Service,
• Managed Network Service from other Service Providers (Telco peersMultiple Cloud Service Providers to support a hybrid Peers)
• Hybrid cloud ecosystem of private and public clouds Etc.from Multiple Cloud Service Providers
• A special case could be composite in house services which include service components managed by a existing domain manager

This use case is also relevant to Single Operator (Single Domain Manager ) environment (e.g. If an operator wants to move its catalog from test to production

...

)

This will be very relevant for automation of digital services delivered via diverse 5G Ecosystem (B2B2X Models) for vertical industry solutions

Funding/Financial Impacts -

...

PNF/VNF : Preference will be to use Fixed Broadband Access Service and associated network functions as reference for this use case. Clearwater IMS will be the backup option

Work Flows:

The use case is being divided into sub use cases in order to limit the scope of changes for E release.

Sub Use Case 1 (targeted for E Release)

Import Service Catalog

Submit Order

Interaction Flow

...

Assumptions and Scope of the Solution

• Business Process on sharing of the information between the 3rd Party Domains and the ODM will be defined in advance.
• Network details for the service order, like IP Addresses for the VNFs will be managed by the 3rd Party Domain
• The 3rd Party order will be enriched by the 3rd Party domain with the details needed for complete provisioning
• Connection details - encryption keys, protocols will be agreed upon in advance between the ODM and the 3rd Party.
• Details like cloud region to be used will be made available in advance.
• Policy will be created with the details of the target site and cloud regions to enable homing.
• Definition of Service/Resource is out of scope for the use case and will be taken up separately
• It is assumed that the service provider will allow controlled access to the API to post service definition. Some SPs may receive the definition from the 3rd Party (over email) and then BSS will invoke the API to add the service definition in ONAP

Sample Internet Service - Service Specifications

Mapping of Service Specifications of the sample Internet Service with the respective domain managers

Image Added

Guiding Principles Followed for this Use Case:

• Minimize impact to existing ONAP Information Model. (No impact to existing SDC model is foreseen based on the analysis done so far)
• All communication from external application with ONAP must be via ExtAPI. This is available today for Northbound Integration for Catalog/Order/Inventory. We would propose to extend this guidance for southbound integration as well.
• Southbound Payload Translation : Any order payload translation towards 3rd Party Domain Manager to stay outside ExtAPI.
• Exposure of third party domain : ONAP will communicate with third party domain and this will not be directly exposed to BSS.
• Controlled access to ONAP SDC Catalog – Only consumers defined in ONAP will have access to post service specification
• Separation of Concerns : Third Party payload for service definition will not have resource level deployment artifacts since resource management is responsibility of third party

Design Time and Run Time View

Image Added

Work Flows:

This sequence diagram depicts external catalog sync into SDC followed by order request from BSSImage RemovedSDC 

Image Added

The flow steps

...

1 – External Third party domain exports it service catalog details to Telstra. Telstra orchestrator ONAP exposes TMF Open API 633 Service Catalog API via ONAP Ext API component. Third Party Domain leverages the API 633 to POST the Service Catalog payload.

POST nbi/api/v3v2/serviceSpecification

Request body –ONAP compatible Service CSAR / (json ??)CSAR – TMF 633 Service Catalog compatible payload

Payload contents:

RFSS for Partner Domain Service

2 – ONAP Ext API updates SDC catalog by invoking internal SDC API

POST sdc/v2v1/catalog/services

3 – Ext API notifies Third party after successful update within ONAP

4 – Service Decomposition happens Service Definition Updates / Creation of Composite Service happen in SDC UI (any manual updates e.g. creating composite service)to the received service definition)

Test, Verify and Distribute the Service definition. SDC updates other ONAP components (which have registered with SDC DMaaP) with catalog details

...

5b – AAI pulls inventory details

Ext API also notifies northbound systems (BSS/NaaS) after successful import of the service catalog into ONAP.

5c - BSS retrieves catalog information from ONAP

This sequence diagram depicts the run time view of Third Party Order Activation using the on-boarded service definition

Image Added

Order Activation Summary

6 – BSS submit submits order using TMF 641 Service Ordering API, that is exposed by ONAP Ext API

...

8 – ONAP SO decomposes the service and , updates AAI with Service instance details

9 a– SO submits the request to internal network domain. This request will follow the existing process of request getting submitted to ONAP to VIM. There can be multiple such domains.

9 b– SO submits the request by invoking Ext API (This is similar to what is being proposed for CCVPN use case as well. This maintains that only Ext API interacts with outside world and other ONAP components do not)9  [Note - There can be multiple 3rd Party domains, After SO decomposes the CFS into multiple RFSs, Ext API will send the request to the corresponding 3rd party domain]

10 – ONAP Ext API invokes the Third Party Ordering APIOrdering API, order translation to 3rd Party format happens outside Ext API, translated order gets submitted to 3rd Party domain

11 – Ext API updates AAI with the RFS instance details received from 3rd party response. AAI topology gets synced with the Service instance details to the level of the RFS instance.

12 - Ext API updates SO with the order item status for the RFS order item. Once SO has received responses for all the RFS order items in the order, it sends a response to Ext API which then responds to BSS with order update.

Sub Use Case 1 (targeted for F Release)

Import Service Catalog

Below sequence diagrams are depicting the Catalog Sync functionality in more detail:

Image Added

High level flow of the activities for importing an external Service Catalog into ONAP with Payload Detail

Image Removed

Sub Use Case 2 (planned for G release)

Automated VNF Life Cycle Management – to cater for change management, incident management and version/configuration management

Service Assurance enablement for Third Party Domains’ exposed services

Control Automation:

Following items for VNF LCM and Service Assurance for Third Party Domain are being considered for the next phase of the use case for F release

...

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

...

Steps 1 to 3 on previous slide - which are part of new functionality -  are explained here.

Steps 4 onward depict existing functionality reused

1 – Invoke TMF 633 Service Catalog API

3rd Party Domain’s Payload to be submitted as a JSON –

Expected format - Service Specification payload specified by TMF 633

2- Ext API to invoke SDC onboarding API to updated ONAP SDC catalog

Invoke ServiceServlet - createService() – JSON payload

Currently on-boarding API is invoked when Create Service button is clicked in SDC UI

Ext API needs to be added as a consumer of the API

Existing logic to be reused:

  UUID creation in validateServiceBeforeCreate

  Logic to add default TOSCA components

2a – Persist the service in SDC database

3-Ext API will Notify 3rd Party after SDC catalog update

  Register for Distribution: Ext API will register itself with SDC.

  Ext API will receive distribution notification from SDC after service catalog creation in SDC

  Ext API notifies 3rd Party Domain

Flow Diagram for Ext API to consume SDC On-Boarding API

Image Added

Flow Diagram for Ext API to register for SDC Service Creation Notification

Image Added

Flow Diagram for SDC Service Distribution - SO Impact

Image Added

Flow Diagram for Service Instantiation - SO Impact

Image Added

Project Impact:

Projects impacted as part of sub use case 1

• SDC
  • In order to import the Service Catalog, Service load will have to be sent to SDC from Ext API.
  • JSON representation of the Service load needs to be identified and agreed with SDC team
• Ext API
  • TMF 633 POST needs to be implemented in Ext API
  • Invoking the Third party Ordering API

...

SDC Impact analysis:

• Expose POST functionality of SDC Onboarding API as an external API within ONAP
• 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 )
• Existing UUID creation logic will be used
• Last mile access service from 3rd party will be used for detailed analysis and reference implementation
• TOSCA based onboarding in work in progress in SDC, it supports heat based only. The TOSCA based work is ongoing separately in Modeling project. This dependency on Modeling project need to be looked into.
• SDC UI Impact analysis is in-progress to identify how to segregate the Third Party services from other services which will have more VF level details associated with them.
• Created epic https://jira.onap.org/browse/SDC-2378 
• We should add metadata in SDC Service metadata definition which indicates whether a service is CFS (public) or RFS (private)

Video showing service on-boarding and reuse in service definition ( in SDC local instance setup at Telstra) :

Attached video takes us through the service creation journey, from creation to distribution-approved, in SDC with the help of the API and SDC UI

Below video shows an example of how the imported service definition can be used to create a composite service

Possible Approaches for 3rd Party Catalog Sync Entity

Entity Option 1 - Resource

• Onboard the resource in ONAP SDC as a VSP, will require updates to VSP onboarding API

Entity Option 2 - Service

• Onboard the service in ONAP SDC as a Service, will require updates to Service onboarding API (proposed)

Sample payload

Image Added

Possible Approaches for 3rd Party Catalog payload Option

Payload Option 1: JSON (Proposed)

• Leveraging existing approach for Ext API / NBI
• ExtAPI / NBI will send the JSON in SDC compatible format for its Consumption in v1/catalog/services

Sample payload

Image Added

Structure of SDC generated TOSCA CSAR

Image Added

Payload Option 2: CSAR

• Potential reuse from TOSCA onboarding Project in SDC
• This might alter existing Ext API / NBI approach
• There would be additional implementation at Third Party end to generate higher level TOSCA

(VLM to be manually created and any service coming from 3rd Party domain should be attached to specific VLM)

Ext API (yet to be analyzed in detail and scoped)

• Introduce POST for TMF API 633 – Service Catalog API
• Realization of POST operation in Ext API will depend on decisions taken during SDC implementation.
• Details of changes are added on Ext API's Frankfurt Release API Requirements Gathering Page
• Ext API changes to be planned for future release (partner contribution during Frankfurt is welcome)

Work Commitment:

Telstra team will work on SDC and Ext API changes. We welcome partner contributions into this usecase.

...