Versions Compared

Old Version 17

changes.mady.by.user Manoj Nair

Saved on

compared with

New Version 18

changes.mady.by.user Manoj Nair

Saved on

Key

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

...

Expand
titleCurrent ONAP Capabilities to Support Interlude

Current capabilities in ONAP External API with respect to Interlude Reference point is elaborated in the presentation by Adrian here. To summarize the capabilities, currently Ext-API supports following types of interactions between Service Provider and Partner (specifically in the context of CCVPN use case, but can be applied in the case of other similar use cases as well

Note: To be verified by Adrian

  • End to End Service is Designed in SDC on SP and Partner side and independently distributed to the respective runtime environments
  • SP or Partner details are prepopulated at respective inventories (A&AI) as customer of the service
  • A service order is placed on the SP side ONAP instance using the Ext-API Service Order API (TMF 641) - using the UUI portal
  • External API decomposes the service order to individual service order items and passes the service order items as a request for service creation to SO
  • SO check the resource requirements - on encountering the SPPartner resource, a new Service Order request is constructed with information available in the SPPartner identifier in the service instantiation request
  • SO places an order directly on the Ext-API of the partner and receives a Service Instance identifier in response
  • SO keeps polling the status of Service instance until service is created/failed on the partner side
  • SO update the SPPartner instance in inventory with the service instance details

Following are some of the short comings in the current capabilities

  • Services need to be independently designed and distributed on either SP and Partner side
  • SP and Partner need to be aware of the Service Specification id to be used while placing the order from either side
  • SO from SP side directly invokes Ext-API on the partner side, not following the separation of concerns - i.e ideally the Service Order management should be limited at the Ext-API layer and Ext-API should act like a gateway between SP and Partner those are governed by contracts
  • There is no contract or policy based interaction control between SP and Partner
  • The scope of interaction is limited (Placing an Order and checking the status of the Order)


Expand
titleExt-API Scope

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.
  • 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

...