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


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

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 :

  • No labels