You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 26 Next »

Project materials can be found here

Name of Use Case: Third Party Operational Domain Manager

Participants : Telstra

Description:

  • A standards-based approach that 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 consumed via Network as a Service (NaaS) w”hich is an abstraction layer above the operational domains and exposes the services to BSS
  • Consistent way of consuming 3rd party services 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

BUSINESS DRIVER 

This section describes Business Drivers for this Use Case.

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. In 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 capability in ONAP for seamlessly on-boarding services from partner (or specific ) domain catalog. Lack of this capability leads to manual creation of partner services in ONAP which is time consuming and error prone. With introduction of this capability, 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 will extend the operational domain manager capabilities to 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 Peers)
  • Hybrid cloud ecosystem of private and public clouds 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 -

  • This use case capability, once developed, can be used by any service provider deploying and using ONAP.  
  • Third Party Domain manger will play a significant role in on-boarding partner domains in a uniform manner.
  • The Service Catalog of the Partner Domain will be made available to the Service Provider in few hours, consumable via an abstraction layer (NaaS in Telstra context). 
  • Once catalog is on-boarded ONAP can publish the Service details to BSS and it can be used for ordering Partner Domain services by the Service Provider.

All this will essentially bring down time to market significantly for partner services.

Organization Mgmt, Sales Strategies - There is no additional organizational management or sales strategies for this use case outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider.

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

Product Modeling and Distribution:

Work Flows:

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

The flow steps

Catalog Sync Summary

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/v3/serviceSpecification

Request body –ONAP compatible Service CSAR / (json ??)

CSAR contents:

RFSS for Partner Domain Service

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

POST sdc/v2/catalog/services

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

4 – Service Decomposition happens in SDC (any manual updates e.g. creating composite service)

SDC updates other ONAP components (which have registered with SDC DMaaP) with catalog details

5a – SO pulls SDC 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

Order Activation Summary

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

7 – ONAP Ext API submits the request to ONAP SO

8 – ONAP SO decomposes the service and 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 – ONAP Ext API invokes the Third Party Ordering API


Sub Use Case 1 (targeted for F Release)

Import Service Catalog

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

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

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

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

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.

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

Possible Approaches for 3rd Party Catalog payload Option

Payload Option 1: JSON (Proposed)

  • Leveraging existing approach for Ext API / NBI
  • ExtAPI / NBI will need to convert JSON to YAML for SDC Consumption

Payload Option 1: 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 this 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.
  • Ext API changes to be planned for future release

Work Commitment:

Telstra team will work on SDC. We welcome partner contributions into this usecase.

The details of changes are being discussed with the PTLs






  • No labels