Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 11 Next »

Project materials can be found here...

Proposal 

Name of Use Case:

Third Party Operational Domain Manager

Use Case Authors:

Telstra

Description:

ONAP ODM in the ecosystem


A standards-based approach that supports on-boarding third party domains and third party service management.

Following can be potential candidates for Third Party Domains which can be managed by ONAP:

  • National Broadband Network (NBN) [Ref: https://www.nbnco.com.au/] Fixed Broadband Service,
  • Managed Network Service from Service Providers
  • Telco peers
  • Multiple Cloud Service Providers to support a hybrid cloud ecosystem of private and public clouds
  • Etc.


ONAP provides Operations Domain Management (ODM) and other complementary capabilities to ensure full automation of the E2E life-cycle management of the service

Services are exposed and consumable via common gateway depicted as Network as a Service (NaaS) layer in figure above.

Consistent way of consuming 3rd party services from the Service provider and orchestration being conducted by the 3rd party within its domain

LCM and assurance events are triggered by the 3rd party service, and remediation response are executed.

Substitutes multiple handovers between parties/teams and applications to enable zero touch automation

 

Users and Benefit:

Beneficiaries – Third Party Domains, Service Providers, Partner Domains

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

This use case is also relevant to Single Operator environment (e.g. If an operator wants to move its catalog from test to production, it can use this import catalog capability to on board the catalog, without manually recreating it in the production ONAP instance.


VNF:

TBD

< list the VNFs this use case will automate/impact/use, be both generic like EPC and specific in terms of software used e.g. which EPC code or vendor product>


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

  • Third Party Catalog import
  • Publish Catalog
  • Submit an O2A order
  • Fulfill the order

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

CSAR contents:

  1. CFSS for Partner Domain Service
  2. RFSS for Network Functions of Service


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

POST sdc/v2/catalog/services

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

2a – SDC Updates SO catalog

2b – SDC updates AAI inventory

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

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

4 – BSS/NaaS retrieves Service catalog details from ONAP

Order Activation Summary

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

6 – ONAP Ext API submits the request to ONAP SO

6a – 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)

7 – ONAP Ext API invokes the Third Party Ordering API



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


Sequence Diagram for 3rd Party Catalog Sync – with Payload Detail

Sub Use Case 2 (planned for F 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

  • 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


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

A&AI (change to A&AI will be analyzed as part of next phase of the use-case, for cross domain inventory management)

Work Commitment:

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

The details of changes are being discussed with the PTLs






  • No labels