While the scope of the current study is limited to short-term Interlude specific capabilities to be supported in Ext-API project and corresponding dependencies, there is also a need to set the long-term scope. Ideally, this requirement should come from the EUAG or the contributors from operator organization. Following are some of the areas identified during the discussions in the Ext-API project. These areas need to be further studied in collaboration with PTLs and EUAG. Note that all these areas are focused on interaction between a Service Provider and Partner(s) Business Cases- NFaaS (Network Function as a Service)
- NaaS /SD-WAN
- SlicingaaS
- MVNO Scenario
- Connectivity as a Service
- NFVIaaS
- Application as a Service (For Edge scenarios)
Operational Use Cases - Dynamic Service Control
- Query Service State
- Update Service
- Request Connectivity Service (across two Service interfaces)
- Query Service Inventory
- Receive Service Notification
- Receive Service Performance Update
- Initiate Service Test
Interlude specific considerations - Layers of interaction, Separation of concerns: Whether to limit the interaction between SP and Partner through a specific layer - for example, Ext-API or support interactions across layer - i.e to support interaction between Ext-API in the Service Provider domain and SO or Controller in the Partner domain. What kind of APIs are used for such interactions?
- Security: Securing the interaction between Service Provider and Partner based on a predefined contract and policy
- Business contract - Policy: Business contract agreed between Service Provider and Partner that will govern the interactions
- SLA Management: The components and method for monitoring and managing SLA including the closed control loop across service provider and partner domains
- Inventory/State Management, Consistency Check, Identity mapping: How inventory across two domains are represented in respective domains, how it is reconciled and how the consistency is checked.
- Direction of interaction : SP to Partner and Partner to SP (as governed by Policy)
- Interface/API – Reference Specification: What standard APIs to be supported over the Interlude reference point
- Licenses: How licenses are controlled across SP and Partner domains, What are the impacts and associated fulfillment implications due to resource licenses.
- Modelling impact: Interlude impact on Modelling work - especially the representation of Partner resources, reachability information, configuration.
- Integration: Requirements for the integration between SP and Partner components via standard APIs, channels for event and performance data collection, reconciliation
- Interoperability: Interaction between SP and Partner, with either one of them having an ONAP instance
- ONAP Role: Assigning roles - such as master, slave to ONAP considering deployments at SP and Partner domains -specifically for coordination of end to end service orchestration and data collection.
Best Practices and Standard Alignment - ETSI GR NFV-IFA 028 V3.1.1 (2018-01)
- ETSI ZSM
- MEF LSO Interlude (link)
- Contributions by Mehmet and Jack
- TMF ODA
- ONAP CCVPN Use Case
- 5GPPP 5G-Ex Project
| 