/
Third-party Operational Domain Manager

Third-party Operational Domain Manager

Owned by Alex Vul (Deactivated)
Last updated: Dec 16, 2019 by Atif Husain
10 min read

Project materials can be 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 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 service specifications 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

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

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

 

 

Work Flows:

This sequence diagram depicts external catalog sync into SDC 

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

Request body – TMF 633 Service Catalog compatible payload

Payload contents:

RFSS for Partner Domain Service