Page History

Overview

MEF LSO defines a set of specifications and reference points aimed at providing end to end service orchestration across multiple network domains using standardized APIs. One of the reference points in this set is interlude which focuses on providing control related management interactions between service provider and partner (link). The other inter-provider reference point in LSO is SONATA which mainly focuses on the OSS/BSS level business interactions. As ONAP is not specifically on the SONATA level of interactions, the rest of the document focuses mainly on the interlude reference point in MEF and similar specifications in other standard organizations. While interlude is one of the reference point and specification which addresses inter-provider interaction, it is worthwhile to look at the broader scope considering typical operational, business use cases and aspects impacting such interactions in ONAP External API specifically and ONAP in general.

Image Added

Another relevant specification worth looking at is 5GExchange project (link) which focuses on "cross-domain orchestration of services over multiple administrations or over multi-domain single administrations" (link). 5GEx project defines a multi-domain logical interworking architecture which covers multi-operator interaction and multi-domain interaction within the same operator.

The topic of inter-provider/inter-domain interaction is being discussed in TMF ODA, ETSI ZSM, but these specifications are still in the early stages of development and may not be relevant in the near future of ONAP development. Another specification worth looking is ETSI IFA 028 v3.1.1 - wherein MANO architectural options to support multiple administrative domains is being discussed. This specification introduces two concepts - MLPOC (Multiple Logical Point of Contact) and SLPOC (Single Logical Point of Contact) with varying degrees of cross-layer interaction and information abstraction across domains. This specification also defines an Or-Or interface across NFVOs in different administrative domains.

Multi-domain vs Multi-provider InteractionTypical Use Cases

Federation and Delegation

Business Agreement

Possible Interactions

Cross-layer Interaction

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 shortcomings 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)