...
Business Impact The use case provides a generic capability in ONAP for seamlessly on-boarding services 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.
...
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
...
This sequence diagram depicts the run time view of Third Party Order Activation using the on-boarded service definition
Order Activation Summary
...
8 – ONAP SO decomposes the service, updates AAI with Service instance details9 – Ext API
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) [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]
...
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)
...
Flow Diagram for Ext API to register for SDC Service Creation Notification
Flow Diagram for SDC Service Distribution - SO Impact
Flow Diagram for Service Instantiation - SO Impact
Project Impact:
Projects impacted as part of sub use case 1
...
- 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
Structure of SDC generated TOSCA CSAR
...
- 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. We welcome partner contributions into this usecase.
...