Versions Compared

Key

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

...

Expand
titleDerived Ext-API Interlude Requirements (WIP)

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 the lifecycle of servicesServices and initiates operations over the inter administrative domain interface
      • Operation Engineer:Manages operational OperationEngineer:Managesoperational tasks
    • Partner A (assuming an ONAP deployment)
      • same as for ONAP SP
    • Partner B (assuming anonONAP deployment)
      • Administrator: Manages lifecycle of Services
      • OperationEngineer Operation Engineer :Manages Operational tasks

Types of Interactions

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

  1. 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
  2. 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.
  3. 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 REST API so that any service impacting configurations or simultaneous access by multiple users can be avoided
  4. 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
  5. 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
  6. 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.
  7. 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
  8. 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)
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
  1. Support for Service Modification API for end to end and nested service through a Patch or Put Request
  2. Handling of Service Modification request with appropriate workflow invocation (dynamic or static workflow)
  3. Management of Service Modification jeopardy conditions - additional workflow
SDC
  1. Modelling of Partner as an external organization resource (Refer SPPartner in CCVPN or TMF632 Organizational Resource)
  2. Ability to attach Partner organizational resource to service
  3. Model Policy templates corresponding to Partner interaction controls as defined in the business agreement
  4. Associate Inter-Provider Interaction Policy with a Partner organizational resource or Service
  5. Generation of internal TOSCA Descriptor corresponding to Partner Organizational Resource
  6. Distribution of Inter-Provider Interaction policies to Policy engine
Policy
  1. Pre-loading (without using SDC) or Design time loading 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



...