Versions Compared

Old Version 70

changes.mady.by.user Manoj Nair

Saved on

compared with

New Version Current

changes.mady.by.user Manoj Nair

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleDerived Ext-API Interlude Requirements (WIP)

Requirement

Any additional capability required in ONAP?

ONAP Capability Requirement

Capability to onboard a partner with associated agreement reference

Yes

Currently a resource by name SPPartner is added to the Service to associate Service with a partner and this resource is distributed to inventory. TMF offers a Partner management API that can be leveraged for adding partner directly

Capability to design policies matching the business contract between SP and Partner
•Guard policies for authorization & access for specific operations
•Configuration policies for restricting the Service parameters and associated boundaries (SLO)

No

This is already supported in Policy UI. Additional policy model elements might be required and Policy templates need to be defined

Capability to associate and activate Partner Service specific policies with SP Service  

No

SDC supports adding additional Policy artifacts for Service

Capability to define Partner Service specific parameters in the SP ONAP Design time environment and persist in Design time/Runtime Catalog

No

Already supported in SDC

Capability to define the Partner Service specific parameters in SP ONAP Inventory

No

Additional OXM root elements might be required

Capability to schedule a Service Configuration/Control in response to a request

No

Required to define Constraint policies that need to be associated with OOF. Additional OOF configuration might be required

Capability to monitor the schedules and initiate the operations between SP and Partner

No

OOF supports this

Capability of SP ONAP Ext-API to initiate a request for Service Configuration and Activation and route it to Partner API gateway

Yes

Ext-API integration with MSB/AAF required. Else need to invoke Partner Ext-API NBI direct from SP Ext-API . Additionally this has to be driven via SO workflows on the SP side

Capability of Partner ONAP Ext-API to receive the Service Configuration and Activation request and carry out validation

Yes

Ext-API to support Service Configuration and Activation API

Capability of Partner ONAP Ext-API to translate the Service Configuration and Activation request and map it to SO specific Service Modification request

Yes

API adaptation logic for TMF 640

Capability of SP ONAP instance to register hub resources for receiving update on the operational request and associated SLO requests placed via the Ext-API

Yes

Enhancement of Ext-API subscription management

Capability of Partner ONAP instance to report errors/events/metrics  based on operational requests

Yes

Enhancement of Ext-API subscription management

Registration of ONAP Ext-API to receive events through DMaaP

Capability of SP ONAP instance Ext-API to initiate test on the Service offered by the Partner either on-demand or based on request received

Yes

Ext API support for Service Test API

Additional ONAP component level support to initiate service test or to query service state

Capability of Partner ONAP instance Ext-API to receive a Service test request and route the request to appropriate components

Yes

Ext API support for Service Test API

Additional ONAP component level support to initiate service test or to query service state

Capability of SP ONAP instance Ext-API to register hub resources to receive notification on tests initiated on the Partner Service

Yes

Ext API enhancement to support additional hub resources

Capability of SP ONAP instance and Partner ONAP instance Ext-API to maintain an external facing identifier for Service Specification and Service Instance

Yes

Ext-API enhancement to manage external facing identifiers and mapping with internal identifiers

Capability of SP ONAP instance Ext-API to delegate authenticate and authorize the operations towards Partner Ext-API through a well established mechanism in ONAP

Yes

Integration of Ext-API with MSB/AAF

Capability of SP ONAP Ext-API to query the Service Instance state and receive notification via hub resource for any changes to the Service state on Partner side

Yes

Enhancement of Ext-API

Capability of SP ONAP Ext-API to register hub resource for receiving any changes to the Service Specification offered by Partner and consumed by SP

Yes

Enhancement of Ext-API

Capability of SP ONAP instance to categorize the Services consumed from Partner under associated namespace in the SP inventory – this namespace may further be associated with tenancy relationship

No

This is supported in AAI (as per CCVPN use case)


Component Specific Requirements (To be elaborated in detail later)
ONAP ComponentRequirement

Ext-API

1.API support for On-Demand Service Configuration and Control - TMF 640 (Optionally support TMF641 based Service Change Requests – [Service Order with action change] as well)
2.Integration with Policy Engine to check the Partner API access policies, authorization, Service change attribute boundaries
3.Integration with SO to invoke On-Demand Service Configuration/Modification Operation
4.Enhancement of Ext-API to map Service Configuration and Activation Request to SO specific Service Modification Request
5.Enhancement of Ext-API to initiate Service Inventory Query on partner side to check the Service State
6.Enhancement of Ext-API to initiate Partner Service Catalog Query
7.Enhancement of Ext-API to support notification of Interlude operations to OSS/BSS
8.Enhancement of Ext-API to initiate Service Test requests on partner
9.Enhancement of Ext-API to support partner onboarding and integration with AAI or Catalog for persisting Partner registration details
10. Enhancement of Ext-API to register Hub resources for querying Partner service states and receive call backs
11.Integration of Ext-API with MSB and AAF to route the API calls to partner through Ext Gateway
12.Enhancement of Ext-API to manage the external facing identifiers and map it to ONAP internal identifiers (Service instance and Service specification)
13.Enhancement of Ext-API to receive events corresponding to the Service changes from A&AI/SO via DMaaP 

SO

1.Support for Service Modification API through a Patch or Put Request
2.Integration with OOF to schedule Service Configuration
3.Additional recipe/workflow for handling Service Modifications locally and for directing it to Partner via Ext-API
4.

External API Requirements for supporting Inter-Provider API

Roles / Actors

    • SP A(ONAP deployment)
      • Administrator: Manages lifecycle of Services and initiates operations over the inter administrative domain interface
      • Operation Engineer: Manages operational tasks like distribution of packages, manage/process work orders
      • Designer: Onboard VNF packages and designs Service Package
      • Tester: Verifies the Service package and approves the package for distribution
    • SP B (assuming anon-ONAP deployment)
      • Administrator: Manages lifecycle of Services and initiates operations over the inter administrative domain interface
      • Operation Engineer:Manages operational tasks
    • Partner A (assuming an ONAP deployment)
      • same as for ONAP SP
    • Partner B (assuming anonONAP deployment)
      • Administrator: Manages lifecycle of Services
      • Operation Engineer :Manages Operational tasks

Types of Interactions

Image Removed

Scenario 1: Both SP and Partner have ONAP

Scenario 2: SP uses Non-ONAP solution and Partner uses ONAP (SP is the Master for all interactions - ONAP at Partner domain is Subordinate)

Scenario 3: SP uses ONAP solution and Partner uses non-ONAP solution (SP is Master)

General User Stories

  1. As a Designer in SP A ONAP, I shall be able to design a composite hybrid service with constituent services that may be realized by SP or Partner, so that I can design the services as per business need.
  2. As a designer of the SP A ONAP I shall be able to represent the access mechanism with end-point URL, security credentials in the partner service abstract model, so that unauthorized access to partner domain can be avoided
  3. As a designer of SP A ONAP I shall be able to create configuration policies that represent access rights, allowed management operations, overall interaction controls so that I can abide by the business agreement between the SP and Parties.
  4. As an Operation engineer of SP A ONAP I shall be able to dynamically register Partner API gateway on the A&AI Inventory so that reachability information to Partner can be configured on demand
  5. As an administrator of SP A ONAP I shall be able to query on boarded Services in the Partner Service Catalog via the SP A External API so that the correct service specification can be verified with the abstract model maintained locally
  6. As an operation engineer of SP A or Partner A ONAP, I shall be able to configure set of management operations that can be accessed on the partner side, so that unsubscribed operation access can be avoided
  7. As an administrator of SP A ONAP I shall be able to query the instantiated services in the Partner Service Inventory via the SP A External API so that state, configured service characteristics of the instantiated services can be verified and reconciled with the local inventory.
  8. As an administrator of SPA ONAP I shall be able to place a request for Service Configuration on Partner API gateway via the SP A External API with appropriate Service Characteristics as defined in a Service Specification so that desired end to end service requirement can be fulfilled.
  9. As an administrator of SP A ONAP I shall be able to enforce the policies for accessing the Partner API gateway from SP A External API so that I can manage the ongoing operational requirements.
  10. As an operations engineer of SP A ONAP I shall be able to define the filter and transformation rules that govern the API requests so that I can route the request to appropriate domain.
  11. As an administrator of SP A ONAP, I shall be able to register for Service notification on the Partner API gateway for receiving any notifications related to Service Configuration and Control Request so that requests placed on the Partner domain can be monitored in an asynchronous manner
  12. As an administrator of SP A ONAP I shall be able to manage life cycle of collectors for receiving the performance related statistics (this can be SLA update) from the Partner API gateway so that performance metrics associated with Partner Services can be collected on demand
  13. As an operations engineer of SP A I shall be able to uniquely identify Service models in the SP domain and Partner domain so that any internal changes to service models is handled by appropriate mapping within respective domains.

Service Configuration and Control Stories

  • As a designer of SP A or Partner A ONAP, I shall be able to identify and represent service characteristics that can be modified on demand so that any unnecessary service impacting changes can be avoided
  • As an administrator of SP A ONAP I shall be able to schedule Service Configuration request through SP A External API to be executed and forwarded to Partner API gateway so that I can ensure optimal execution of request based on the desired condition.
  • As an administrator of SP A ONAP I shall be able to lock or unlock a partner service configuration and control through SP A External API so that any service impacting configurations or simultaneous access by multiple users can be avoided
  • As an administrator of SP A ONAP I shall be able to assign mastership of the Partner Service (Partner owned, configured or SP owned configured) to SP A or Partner so that Service updates are carried out in a consistent manner
  • As an administrator of SP A or Partner A ONAP, I shall be able to check the feasibility of Service configuration and control on the Partner domain so that I can ensure that the subsequent configuration request can be fulfilled without issue
  • As an administrator of SPA ONAP Is hall be able to activate or deactivate a Service on the Partner domain via the SP A External API exposed REST APIs so that the partner services can be used during desired period and desired condition.
  • As an administrator of SP A ONAP I shall be able to check the status of a Service Configuration and Control request placed on the Partner API gateway in an asynchronous manner so that state of the service can be updated in the inventory
    • As an administrator of SP A ONAP I shall be able to retry a Service Configuration and Control request on the Partner API gateway or recover from the error by executing a predefined recovery logic so that Service jeopardy condition can be mitigated.

    S3P Related stories

    1. As an administrator of SP A I shall be able to initiate the request to Partner over a secure channel so that my requests have not tampered and I can ensure that the request reached the intended endpoint
    2. As an Operation Engineer of SP A I shall be able to assign role-based access for the interaction with Partner administrative domain so that unintended request initiation can be avoided
    3. As an Operations engineer of SP A I shall be able to manage the credentials of accessing the Partner accessing the domain so that the access can be controlled and restricted.
    4. As an Operations engineer of SP A I shall be able to log, audit the access attempts and requests to Partner administrative domain so that any unintended access attempts can be traced and reported.
    Component Specific Requirements (To be elaborated in detail later)
  • Support for Service Modification API for end to end and nested service through a Patch or Put Request
    • endpointAAF
    ONAP ComponentRequirement
    Ext-API
    1. API support for Service Configuration and Control - TMF 641, TMF 640 (or TMF 655)
    2. Integration with Policy Engine to check the Partner API access policies
    3. Integration with OOF to schedule Service Configuration
    4. Integration with SO to invoke Service Configuration Operation
    5. Integration with SDC Catalog to fetch Service Model details
    6. Integration with A&AI to check and update the Partner service status
    SO

    Handling of Service Modification request with appropriate workflow invocation (dynamic or static workflow)
    5.Management of Service Modification jeopardy conditions - additional workflow

    SDC

  • Modelling of Partner as an external organization resource (Refer SPPartner in CCVPN or TMF632 Organizational Resource)
  • Ability to attach Partner organizational resource to service
  • Model Policy templates corresponding to Partner interaction controls as defined in the business agreement

    • 1.Ability to refer Partner registration details either passed on via Ext-API to SDC Catalog or provided as input during design
    2.Design and use Policy templates corresponding to business agreement
    3.Associate Inter-Provider Interaction Policy with a Partner

    organizational

    resource or Service

  • Generation of internal TOSCA Descriptor corresponding to Partner Organizational Resource

    • 4.Distribution of Inter-Provider Interaction policies to Policy engine

    Policy

    1.Pre-loading (without using SDC) or Design time loading (through SDC) of Policy templates for inter-provider interaction policies
    2.Creation of Policy for controlling inter-provider interaction control
    3.Deployment of inter-provider interaction policies to corresponding PDP (PDP-X)
    4.Configuration/Control of PEPs (Ext-API) with Configuration or Guard Policies corresponding to external triggers received by PDP-X

    AAF/MSB

    1.Configuration of namespace for representing the SP or Partner Ext-API end

    endpoint AAF
    2.Creation of Authentication Certificates (Client and Server)
    3.Interaction of AAF across administrative domains
    1.Creation of Permissions for SP and Partner Ext-API endpoint as per the policies configured.

    OOF

    1.Capability to schedule the on-demand service configuration
    2.Capability to check the capacity and relevant partner end point for enabling an on-demand service configuration

    DCAE

    1.To receive Service related notifications from Partner ONAP instance
    2. To direct the events to Policy and carry out closed loop control locally at the Partner side or on the SP side for E2E Service
    3.Correlate Service related events and enrich with inventory data before passing on to Policy engine

    Expand
    titleOperational Threads (for Discussion)

    Image Added

    Operational Threads SONATA and Interlude with ONAP Components - Draft for Discussion


    Image Added

    Service On-boarding


    Image Added

    Service Creation


    Image Added

    On-Demand Service Control

    Expand
    titleONAP Dublin Requirements

    Requirements

    Study how we can control modification requested at Interlude level – they are at least 2 subtopics there:

      • Identify where the information could be managed within ONAP (in SDC ? have attribute change value and state change authorized at SOF-SOF interaction level ?)
      • Explore if External API can be used by internal ONAP Components as a proxy to talk to external Partner ( e.g. ONAP 1 SO call ONAP 1 ExtAPI, then ONAP 1 ExtAPI call ONAP 2 ExtAPI ) i.e. ONAP internal components can communicate securely internally, External API act as proxy to forward request ( e.g. Service Order ) to Partner ( maybe a Partners ONAP External API Framework ). 
      • Define the API (resource model) that allow the system to request ‘authorized’ service modification (Policy API ?)

    Dependency on other projects

    ...