Page History

Operator/EUAG

• Do we need to consider intraoperator multi-administrative domain interaction – i.e communication across different instances of domain orchestrators (ONAP or non-ONAP) belonging to the same operator?
• Do we need to limit the scope of Interlude to Service Control, Activation, and Configuration or include Service Order Management?
• Use Cases: What use cases we should consider for the interlude specification? Generic Operational use cases (Service activation, query etc)  or Specific Business use case ? (NaaS, NFaaS, Access E-Line etc) – Short term and Long Term Target?
• Consideration for interaction between ONAP and non-ONAP (Legacy) Management system across operator domains
• Strategy for closed-loop control (Assurance) – Who will manage? Partner managed or SP managed
• Resiliency requirements for inter-operator management connectivity – Failover mechanisms
• Do we need to consider interdependency inter-dependency of Interlude and Legato/Sonata interface? (for example contract) 
• Service Impact Assessment - Need for doing a Service impact analysis before any operation over the interlude
• Need for Service Change Management: Interlude operations to be initiated as work order through a Change management API (e.g. TMF 655) - Is this the practical mode of operation? Or expect a more dynamic service control operation?
• Dynamic or Static workflows to be supported to accommodate Interlude operations (SO and beyond) and beyond)
• Direction of interaction - Do we need to consider direction of interaction (SP initiated or Partner initiated) ? OR assume the initiator of the request over interlude is always the SP ? i.e Do we need to always have a client and server at either end of the administrative domain ?
  • Initial View : The interaction should be always initiated by the SP admin domain. Ext-API should have flexibility to act like a client or server of request.
• Need for distribution of policy across administrative domains - Policy FW currently supports PAP, PDP level functional decomposition. Assuming PAP is managed by SP and PDP functionality deployed at SP and Partner ONAP instances, do we need to consider distribution of policy across admin domains ? Is this relevant in interlude ?
  • Initial view : This is beyond scope of Ext-API or interlude
• Need for supporting ETSI Or-Or interface (ETSI SOL011) at Ext-API level or it can be supported as a component level (SO or VFC) east-west API
  • Update from Ext-API meeting 11/14: This is not in the scope of Ext-API and should be handled by an ETSI compliant NFVO function in ONAP (VF-C for example)

Architecture Subcommittee

Onboarding and distribution model for of SP and Partner Service Descriptors - Controlled by separate SDC instances or by common SDC instance

• Catalog and Inventory Management – Strategy for 1) onboarding the catalog with service specification across interdomain boundaries 2) Reconciliation and aggregation of inventory at each domain – Pull vs Push model
• ONAP specific terminology: Different SDOs follow different terminology e.g. operator interoperability, domain interoperability, administrative system interoperability etc.
• Cross-layer interaction requirement and the need to accommodate this as part of interlude scope: for example OOF layer of SP need to interact with Multi-VIM of Partner for resource utilization, SDNC of partner sharing data to DCAE of SP (both not via Ext-API interlude but inter-component APIs) – Is this model valid (MLPOC as per ETSI IFA028 )
• Federation vs Delegation
  • Update from Ext-API meeting 11/14 : Only a federation method is considered for Ext-API
• Federation actors and Roles: What type of provider roles we should consider ? Infrastructure provider, Connectivity SP, Partner SP, Master/Slave), Do we also need to consider different layers of partners – infrastructure, connectivity etc.SP, Master/Slave), Do we also need to consider different layers of partners – infrastructure, connectivity etc.
  • Update from Ext-API meeting 11/14: Interlude scope is at service layer. So infrastructure, Connectivity etc is irrelevant and as long as the interaction is limited to the service, there is no need to differentiate the layers
    
• Need for including the Business layer interactions within the scope of interlude (for example dependency on Service Policy), Service Creation (in the absence of Business Application)
• Separation of concerns: All external facing interactions to be managed via External-API, Should SO be Service Order aware?
• Need for supporting Or-Or interface over the interlude reference point
• Mastership Management : Should Ext-API assign mastership roles for getting exclusive right to initiate request over interlude ?
  • Update 11/14: The mastership is always with SP system. Right now the interlude scope is between systems in two administrative domains. So Ext-API need not consider this as a requirement.
    
    

Modeling Subcommittee

• Service Model Impact: Service hierarchy in the Service model – i.e Composite or Nested Service, Constituent Service – How the service model is decomposed and distributed to operator and partner domains? Any pattern to follow? Or based on request attributes?
• Representation of Partner Service and Resources , Partner Registration data, Policy, Service associations between SP and Partner in Inventory
• Use of Allotted Network Function vs SPPartner for representing Partner Service
• Data Model Alignment for Ext-API : TMF vs MEF vs ONAP runtime model
• SPPartner and ANF have similar functionality - Are they redundant ?

Security Subcommittee

• Security mechanism to be established between parties - Recommendations and guidance
• Regulatory guidance : What kind of regulatory checks to be incorporated

Project team input

• SO: Plan for supporting Service configuration, Service change - What REST APIs to use PUT or PATCH of Service or a dedicated action
• Policy: Representation of confguration policies for cross operator interaction, representation of constraints for scheduling operations on Interlude
• SDC : Modelling and managing Partner services, service access points, distribution of service
• A&AI : Representation of partner resources and services

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:Managesoperational 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

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

Component Specific Requirements (To be elaborated in detail later)