Service Resolver

BUSINESS DRIVER



Executive Summary - Provide the capability to define&instantiate service, in a model-driven approach, selecting service deployment flavor based on rules.

Business Impact - Capacity to build & deliver customer services

Business Markets - all

Funding/Financial Impacts -

Organization Mgmt, Sales Strategies - Service Architect, Service Designer, Business view to Technical implementation view



SUPPORTING FILES

Presentation

File

Presentation

File

Service Resolver presentation in Architecture Comitee (18th June 2019)

Service Resolver



The solution must be :

  • generic : any kind of service (vFirewall, Internet Access, virtualBox, Network Slice service, monitoring service...)

  • model-driven : no need for "per service“ code, only service definition (data in database via API)

  • adaptive to the context : the service "solution" is evaluated/defined at the moment a service order is received, based on rules

  • standard API based : TMF641 (serviceOrder), TMF633 (serviceCatalog), TMF638 (serviceInventory)

  • usable in simulation mode (without ONAP) to allow Service Designer elaborate/test their service definition before deploying the service definition for real with ONAP

  • very simple to use : only one Json additional file to define Customer Service

A possible solution has been validated by a Proof-of-Concept (full Python based) : Service Resolver

That solution is using CFS/RFS concepts (Customer Facing Service / Resource Facing Service).

The main assumption is : "service" notion from ONAP SDC is equivalent to RFS specification.

The proposal then implements an additional "customer service" modelling layer and some instantiation rules that are evaluated when receiving a service order.



You can install and play with it :  https://gitlab.com/Orange-OpenSource/lfn/onap/service-resolver