Page Comparison

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. MEF Interlude scope is covered in detail in a separate section.

5GExchange (link) as part of 5GPPP is one of the relevant project worth referring 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. As part of the 5GEx project a detailed study is being conducted around inter-domain and inter-provider interactions and results are published here. The 5GEx proposed system consists of multi-domain orchestrator (MdO), domain orchestrators and interactions between MdO (marked as #2 in the diagram below), the interaction between MdO and Domain orchestrators (marked as #3 in the diagram), the interaction between customer and MdO (marked as #1), interaction between Domain Orchestrators and controllers (marked as #5) and interaction between domain orchestrators (marked as #4). Each of these interactions is identified by different types of interfaces. There is also a classification based on business level interactions, management/orchestration level interaction, control level interactions, and data level interaction. Out of these #2 is the one which close matches the MEF interlude reference point, but the scope is slightly different because in 5GEx project business, management/orchestration related interactions are expected to be handled by the same interface (i.e #2). While #3 (between MdO and DO) is quite relevant in the case of External API, this may be an item for future study as domain orchestration concept is currently under discussion in ONAP Tiger team as of September 2018. For the sake of this document, MdO is functionally mapped to the External API component in ONAP as it is providing an end to end service management capability.

Image Modified

Following diagram captures the interface mapping to standards as defined by 5GEx in their functional model found here

Looking at the picture above, it can be observed that 5GEx mostly follows the ETSI MANO specific interfaces for interactions across MdOs or between MdO and DO. But the picture also includes some additional scope as listed below

• Topology distribution across domains for exchanging network topology details that may be used by MLPCE.
• Multi-domain path computation engine interaction across domains for exchanging path specific data
• SLA Management interaction across domains for exchanging business agreement.
• Service Catalogue interactions across domains for exchanging service specifications

Summarizing the scope in5GExproject, its key focus is in virtualized infrastructure with ETSI MANO building blocks with additional scope for exchanging the network topology, network path, business agreement and service specification across different domains. For ONAP Ext-API this may not be quiterelevantasitfunctionsatalayerabovetheNFVO. However, if External API scope is expanded to have cross-layer interaction, i.e MdO of one operator domain interacting with DO of another operator domain 5GEx specific interfaces may be relevant. But what can be learned from the 5GEx project is the concept of SLA Management, Catalogue exchange, Security mechanisms and approaches for supporting use cases such as Slicing.

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 referring 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) andSLPOC (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. As described in the case of 5GEx, ETSI Or-Or level interaction may not be of immediate focus for External API project in the context of Interlude. However this may be relevant in case Ext-API is promoted as a sole external facing component from ONAP and interaction between two VFC or SO systems need to be enabled across operators favoring the ETSI SOL0011 interface. This requires further discussion with the architecture team and EUAG.

SDO/OSSP activities around inter-provider APIs are covered in detail in subsequent sections.

Update 11/14 : As per discussion in Ext-API weekly call, the scope of Ext-API will not cover multi-level interaction (similar to MLPOC referred in IFA 028) . So the interaction will be limited to communication between Ext-API in SP and Partner domain. The reasoning is that MEF interlude scope is interaction of functions at Service level and not between functions in the Service and Resource level.

Multi-domain Interaction

As defined in 5GEx project multi-domain can be multiple network operators or it can be multiple subdomains within a single operator. The scope of interaction might be slightly different within single operator domains and across multiple operators because the latter will be governed by SLAs with strict policies and predefined trust/contract between the two operators. So security and trust are some of the key criteria for interaction across multiple parties. All interaction should be governed, policy controlled based on the trust agreement. Within the same operator domain, there can be multiple administrative domains which can be governed by SLO/OLOs and trust agreement as in the case of inter-provider interaction. But there can also be a model of distributed deployment which may not fit into the purview of multi-domain interaction. For example, geo-redundancy and HA deployments may not be classified as multi-domain interaction, but governed mostly by policies defined between two software components and interaction over internal APIs. Another consideration for multi-domain is the scope of domain - for example, a domain might just focus on the legacy network or a domain might focus on providing WAN services or another domain may implement only the network control capability without orchestration functions, or it can be a classification based on infrastructure, platform services. In all these cases the relevance of multi-domain might be applicable but need to be read along with the federation-delegation models and the administrative boundaries that separate through a business agreement. The topic of Domain orchestration is under discussion in ONAP as well as other SDOs. So this topic may be revisited at a later stage.

Form Ext API point of view the relevance of interlude level interaction is mostly between two administrative domains those are governed by predefined policies and offering services that can be queried and consumed within the purview of the agreed policies.

Federation and Delegation

Similar to multi-domain interaction, federation and delegation are two terminologies used for interaction between two logically separated endpoints. While there is no standard terminology defined at the ONAP level, we can assume federation to be the east-west interaction between systems/components at same logical domains- for example between Orchestrators in two administrative domains, or controller in two administrative domains. The delegation terminology can be associated with the interactions between systems/components at different logical domains- for example, an end to end orchestrator interacting with a domain orchestrator. Federation and Delegation can be classified with reference to the diagram above from 5GEx. Interactions marked 2 can be classified in federation and interaction marked 3 and 5 can be classified as delegation. Here the federation is across domains of different operators, whereas delegation is between the same operator domains. Another differentiator is that federation is between logical domains with similar scope whereas delegation is between logical domains with a different scope. The logical separation can be based on the technology abstraction, geographic abstraction or deployment model. One example of the federation model is the interactions in the CCVPN use case where a partner operator service is initialized and consumed. An example of the delegation model is interaction possible between the central site and edge site orchestrators in an edge automation use case.

In the ETSIIFA028there are two models of inter-administrative domain interactions -SLPOC (Single Logical Point of Contact) and MLPOC (Multi Logical Point of Contact). In SLPOC there is a single interaction point between two administrative domains whereas in MLPOC there are multiple interaction points between administrative domains. In simple terms, it is possible based on ETSI MLPOC model for NFVO in one administrative domain to interact with VNFM or VIM in another administrative domain over the ETSI interfaces. Since External API functions at a layer above NFVO, the current scope of interaction is limited to the federation model described above -i.einteraction between External API in two operator domains.

The delegation model support in External API requires further discussion based on specific use cases. There is also discussion around Recursive Orchestration, Orchestration Hierarchy and Domain Orchestration. The delegation model can be considered within the scope of External API once some concrete decision is made by the Architecture team. For the current scope, only the federation model is considered.

Business Agreement and Policy

MEF Interlude does not have a specific scope for managing the Business Agreement between SP and Partner, however, the interaction between the parties might be governed and controlled based on the predefined business agreement and associated policy rules, security mechanism. 5GEx document on Business and Economic Layer (link) elaborates this aspect in detail but limits the focus on the SLA between parties. Some interesting aspects to be considered for Interlude are as follows

• Roles of the parties (SP and Partner) which will determine the mode of communication, specific controls required at either end, Policies to be enforced, the direction of communication (Some examples given for the 5G case are - Infrastructure Service Provider, Network Service Provider, Communication Service Provider, Over the top service provider, Exchange point service provider . The roles defined by 5GEx are mostly inspired by those defined by 3GPP 28.801.
• Centralized vs Distributed Interaction: The interaction between parties can be centralized i.e coordinated by an aggregator provider acting as an exchange point between parties or it can be one to one. The aggregator model is better as it will avoid the need for multiple business agreements while ensuring centralized enforcement SLA and policies
• Coordination model: Consists of two phases - publishing phase where information is exchanged between parties on the offered services and service composition phase when the actual customer request for a service is forwarded from one party to other. In the case of Ext-API this will be translated to a query on the other parties Service Catalog and initiation of service Configuration/Control Request
• Agreement Push vs Pull Model: In Push model the Business Agreement and policies are predetermined/agreed before any interaction between parties over the inter-provider API whereas in pull model business agreement is dynamically decided based on the customer request and required SLA, monitoring levels.

The 5GEx project defines Business Agreement in terms of SLA and the document referred at the beginning of this section also gives a template for defining SLA. For ONAP Ext-API this may not be useful as it currently does not have any referenceable entities for defining policies for interaction between parties, which is quite relevant at the interlude level.

Other relevant SDO References for adapting Business Agreement are as follows

• TMF B2B2X Partnering Step by Step Guide (link): Lifecycle model for B2B partner management, templates for B2B agreement mostly focused on the business layer, but the operating agreement may be relevant for defining the interlude policies
• Recent ONS presentation on BlockChain based inter-operator agreement implemented based on HyperLedger (link)

ONAP Policy Framework support creation of Guard Policies and Blacklist Guard Policies based on a specific Policy Model (link). These are decision policies with a "Permit" or "Deny" response. While this is one potential option to control interaction between microservices or components within a single instance of ONAP, when it is applied to the inter provider APIs , need to check whether the Guard policies can be used as is or need to be augmented with additional properties. Another aspect to consider is the NBI that need to be exposed to create the policies, i.e to extend the existing Policy APIs via Ext-API.

ONAP Policy FW also support creation of Configuration Policies. These are set of key value pairs which indicate the applicable limits for certain conditions/contexts. In the Ext-API context Configuration policy can be reused to store the partner resource access control parameters, conditions. In either cases (i.e Guard or Configuration Policy) EXT-API act like a Policy Enforcement Point and may trigger policy requests based on API invocations.

For External-API project a new set of APIs needs to be defined between Business Application layer and SOF over Legato to push the policies for interacting with the partner. In the absence of this API, it may be assumed that Ext-API will consult the Policy Engine in ONAP for determining the control mechanisms that need to be established before interacting with the partner over the inter-provider API.

Cross-layer Interaction

IN MEF LSO, the interlude reference point is between SOF in Service Provider domain and Partner Domain. If this principle is strictly followed the interaction can be confined to External API level or External API+SO combined. i.e SOF functionality can be assumed to be fulfilled using Ext-API and SO as a unified block. However, in practical deployments, there may be scenarios which might require cross-layer interaction, for example, MLPOC proposed in ETSI IFA028 wherein the Orchestration function in one domain interacts with VIM or VNFM in another domain. The multilayer interaction might also be possible in a hybrid orchestration scenario wherein the Virtualization and Non-Virtualized domains might have to interact at different levels - for example, a MEF LSO compatible system needs to interact with a non-MEF LSO compatible system. One more practical case is the domain orchestration scenario wherein different logical domains interact with each other. This is a wider consideration and decision requiring input from architecture subcommittee and EUAG.

Another aspect of inter-operator cross-layer interaction is cross-layer data reconciliation say at the inventory level or at the assurance level assuming the cross-layer interaction is permissible as per the business agreement and requires for efficiency. But this aspect is outside the scope of the interlude and may be a topic for wider discussions across SDOs.

For the scope of External API in the short term it is assumed that the cross-layer interaction is limited to the interaction between two systems in SP and Partner domains at least one of those is Ext-API component and other one is the entity which is logically equivalent in functionality and having permissible scope and APIs as defined in the MEF interlude specification and compatible with the Agreement between the two parties (SP and Partner)

Update 11/14: As per discussion in External API Weekly call, cross layer interaction is not in the scope of interlude or Ext-API. Hence this consideration may be parked.

Design Time Impact

In the CCVPN use case the Partner capabilities and management connectivity details are represented using a place-holder resource by name SPPartner. The SPPartner model is given in the link here. The CCVPN use case assumes that Services are designed independently by SP and Partner by respective Design time environment. This means that there will be redundant Service descriptors on the SP and Partner Design time catalog. The Service Model ID in SDC catalog is used to associate a Partner Service ID with a Service Specification in Inventory on either domain. Additionally, the Service Model ID maintained in the SDC catalog by the other party is manually referred for invoking operations - for example as a payload parameter on Service Order Management across SP and Partner. In practical scenarios, such redundancies and manual referencing cannot be avoided but if either domain use ONAP it shall be possible with additional capability on the design-time environment to design services using a single instance (managed by SP) and distribute the service models to both SP and Partner runtime environment.

From External API point of view, since it refers currently to the SDC Catalog for any Catalog management operations, there may be a need to identify the service specifications uniquely between SP and partner and refer to such specification for any interactions like Service Configuration and Control. There is also a need to reconcile the service specification based on incremental changes or versions updated in the design time catalog on either domain. Without such reconciliation and associated validations, the interactions may be inconsistent.

Another important consideration is maintaining the internal view of the service specification and external view. For example the Service Model Identifier maintained within External API can be considered as an external reference for the service specification whereas the Service model id within SDC catalog can be viewed as the internal ONAP identifier for the service model. The mapping between these two may be stored either in SDC or in External API. While referring to service specification over interlude reference point it may be more appropriate to use the identifier used by External API.

Mastership Management

In all practical cases, a typical SP may have to manage a group of Partners and corresponding inter-provider interactions. In such scenarios, it is important to assign the roles of the SP and Partner as to what each party is authorized on the SOF-SOF reference point. It is also possible that a Partner SOF is managed by multiple SPs or the SPs have a peer to peer relationship between them with each playing different roles at different contexts. As the interlude reference point focus on the Service Control and Configuration, it is important to ensure that simultaneous Service modification is avoided. One of the key requirement here would be to assign designated roles (mastership) for SP or Partner as to who is authorized to make Service related changes. Another requirement might be that before initiating any Service control the respective resources/applications are locked in inventory or through access control mechanisms. From Ext-API point of view this leads to a requirement to define the roles and authorizations while creating the Partner registration in inventory. This can be supplied either at the design time (through SDC - for example, while creating the SPPartner resource) or at runtime/design time through Policy association with a Service. Another option would be to leverage the ESR provided capabilities to manage the Partner registration where appropriate restrictions can be incorporated. The particular model of mastership assignment needs to be discussed further and selected during the implementation time.

Update 11/14: As per the discussion in Ext-API weekly call Master-ship management is not critical requirement in near future. In the MEF interlude context the chances of many to many interaction or delegation of control to a Partner are yet to be finalized. With this input, it is assumed that Ext-API will not need an additional parameter to check the mastership before initiating interaction over interlude.

Run-time Identifier Management and Tracking

This section mainly focuses on the identifiers shared between SP and Partner - For e.g.Service Specification being referred by the Service Provider and Partner at the Ext-API level, the mapping between Service specification used in Ext-API and ONAP SDC Catalog Service Model Identifier.