...
Expand | ||
---|---|---|
| ||
OverviewMEF 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. 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
Summarizing the scope in 5GEx projectin5GExproject, 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 quite relevant as it functions at a functionsata layer above the NFVO. 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) and SLPOC 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 sescribed Assescribed in the case of 5GEx, ETSI Or-Or level interaction may not be Subsequent sections in this page cover a comparison of different SDO/OSSP activities around inter-provider APIs. Multi-domain InteractionAs 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. Federation and DelegationSimilar to multi-domain interaction, federation and delegation are two terminologies used for interaction between two endpoints. While there is no standard terminology defined at the ONAP level, we can assume federation to be the east-west interactions 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 and 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 ETSI IFA028 there ETSIIFA028there are two models of inter-administrative domain interactions - SLPOC and SLPOCand MLPOC. 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.e interaction einteraction between External API in two operator domains. The delegation model support in External API requires further discussion based on specific use cases. Business Agreement Possible Interactions Cross-layer Interaction Security Standard APIs Information/Data Model Open Questions
|
Expand | ||
---|---|---|
| ||
Interlude Scope as per MEF55Referring to MEF55 document the Interlude reference point is used by Service Orchestration Functionality to request initiation of technical operations or dynamic control behavior associated with a Service with a partner network domain. The dynamic control (Service Control Orchestration) behavior is elaborated in section 8.2.3 of MEF55 as
MEF55 also differentiates Order Fulfillment Orchestration, Service Configuration and Activation, Service Control Orchestration. While Order Fulfillment Orchestration deals with establishing or modifying a service through the ordering process, Service Control permits the service to be dynamically changed within specific bounds described in policies that are established at the time of ordering. After a service is provisioned and established, LSO may enable Service Control to Customers/parties, such as the ability to modify attributes subject to schedule policies and service constraint policies with for example specified ranges of valid values. Service Control relates to capabilities such as turning on or off connections, throttling bandwidth or other QoS characteristics, etc. So considering the scope in MEF55, Interlude reference point is primarily used for Service Control Orchestration. Here Service Control Orchestration is considered to be an activity enabled after service is being provisioned. So service order management is not defined in the scope of MEF Interlude but expected to be carried over the SONATA interface (Product Order Management) and Legato (Service Order Management, Service Catalog Management). MEF Interlude InteractionsThe interactions factored in the MEF Interlude Reference point are as follows
The green one's are interactions currently supported in External API across SP-Partner as part of the CCVPN use case. In addition to the above-listed capabilities Ext-API also supports following interactions
The last two interactions are not specifically scoped as part of Service Control Orchestration in MEF55, but in the External-API discussions it was also clarified that Service Orcder management API can be reused for placing the Service provisioning request and also for Service Control/Configuration. This may be used as an additional capability in the absense of a full fledged OSS system through which the Product Order and specific contracts that can be exchanged between parties. Out of the missing capabilities, dynamic service control, service-specific event notifications and service-specific performance information exchange between the service provider and partner are some of the key capabilities that need to be enabled in ONAP Ext-API to support interlude reference point. Interlude Related Work Items in MEFTBD |
...