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
      • 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 services
      • OperationEngineer :Manages operational tasks
    • Partner A (assuming an ONAP deployment)
      • same as for ONAP SP
    • Partner B (assuming anonONAP deployment)
      • Administrator: Manages lifecycle of Services
      • OperationEngineer :Manages Operational

Types of Interactions

General Requirements

  1. As a Designer in SP A ONAP, I shall be able to design a hybrid service with constituent services that may be realized by SP and Partner, so that I can represent services in an abstract model which may be used by the ONAP runtime environment.
  2. As a designer of theSP AONAP I shall be able to represent the policy and security credentials in the partner service abstract model to access the partner API gateway (the equivalent of Ext-API on the partner side) so that unauthorized access to partner domain can be avoided
  3. As a designer of SP A ONAP I shall be able to represent the URL of the Partner API gateway in the partner service abstract model so that reachability to partner API gateway can be ensured.
  4. As an Operation engineer of SP A ONAP I shall be able to 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 onboarded Services in the Partner Service Catalog via the SP A External API exposed REST APIs so that the correct service specification can be verified with the abstract model maintained locally
  6. 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 exposed REST APIs so that state, configured service characteristics of the instantiated services can be verified and reconciled with the local inventory.
  7. As an administrator ofSPA ONAP I shall be able to place a request for Service Configuration on Partner API gateway via the SP A External API exposed REST APIs with appropriate Service Characteristics associated and as defined in a Service Specification, so that desired end to end service requirement can be fulfilled.
  8. As an administrator of SP A ONAP I shall be able to control and enforce the policies for accessing the Partner API gateway from SP A External API so that I can manage the ongoing operational requirements.
  9. As an administrator of SP A ONAP I shall be able to place a change management request for service offered by the Partner via the SP A External API so that I can ensure the subsequent or constituent partner service impact and mitigation actions can be initiated in advance.
  10. As an administrator of SP A ONAP I shall be able to filter the API requests on SP A External API and as needed and forwarded to Partner API Gateway so that SP A runtime components are not loaded and real time Partner Service state can be realized and reconciled.
  11. As an administrator of SP A ONAP I shall be able to schedule a work order via a Change management request through SP A External API, prior to/along with a Service Configuration or Control Request so that I can ensure optimal execution of request based on the desired condition.

Service Configuration and Control Requirements


Requirement mapping to ONAP Components
ONAP ComponentRequirement No




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

...