...
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subsequent sections in this page cover a comparison of different
Federation and DelegationSimilar to
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. Business Agreement and PolicyMEF 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
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
For External-API project a new set of APIs needs to be defined for the Business Application layer 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) SecurityTBD Standard APIsMEF Interlude is a reference point which is expected to accommodate many APIs going forward based on the scope defined. Few examples of APIs that may be suitable as per the scope in MEF 55 are as follows
List of TMF Open APIs can be found here TMF Notification Patterns - link Information/Data ModelThere are multiple models found to be relevant for inter-provider API
The choice of a specific model will depend on the decision of EUAG, TOSCA Task Force in ONAP. From Ext-API point of view it is expected to leverage the CFS/RFS model being referred by the TMF 641 API . In future as Interlude specific model in MEF and MEF Services Common Model matures appropriate mapping can be incorporated to accommodate specific service characteristics to the TMF APIs. In MEF LSO there is also NRM model being used for the Presto interface (derived from ONF). The NRM model is assumed to be out of scope for Ext-API unless there is a cross-layer interaction between SOF in SP domain and ICM in Partner domain is required. Open Questions
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Expand | ||
---|---|---|
| ||
Operational ThreadsReferring to the MEF 55 Operational Threads as documented here, there are two levels of interactions between service provider and partner - at the Business Application level (over SONATA reference point) and SOF level (over Interlude). The SONATA reference point is out of scope for ONAP, however, the interactions over interlude will have some dependency over the interactions on Interlude reference point. As per the operational thread given above, following are the interactions at SONATA and Interlude reference point SONATA (BUS<->BUS)
Interlude (SOF<->SOF)
There are two options of interactions between SP and Partner Option A: A product order is placed on the SONATA Reference Point and a separate Service Configuration request is sent over Interlude Reference point Option B: Product order is placed on the SP, the business application layer creates a separate Product Order over the SONATA interface to Partner for the creation of interfaces, NF and connectivity. The first case may be more suitable when the Service fulfillment request needs to be controlled by the Business application layer and any dynamic control need to be handled by the SOF level. Second case is more suitable when the Business application layer needs to control all type of interactions between SP and Partner. In Casablanca release in the absence of the SONATA interface in ONAP a variant of OPTION A is being implemented without the service configuration. Additionally, the interaction is at a service order level rather than product order level. While this can continue in future releases, the scope of interlude is more focused on Service Configuration than Service Creation. 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. Note that 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). While this clearly defines the scope of Interlude, there may be consideration of API and additional capabilities that a specific API supports in addtion to the defined scope. For example while the interlude reference point is meant for Service Configuration and Control for an already provisioned Service, use of Open API like TMF 641 (Service Order Management) at Interlude reference point may bring in additional capability of creating a service if either parties support such interactions. 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 in 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 being supported for CCVPN use case in the absence of a SONATA interface at the Business application layer. As described above, while Interlude scope is limited to Service Configuration and Control, the API used for the interaction across the SP-Partner can be TMF 641 - Service Order Management as this API provides an option to include multiple Service request in a single API call, unlike in TMF 640 wherein each Service request need to be split as separate API invocations. Alternately partner domain Service Configuration and Control can also be initiated through a work order supported through the TMF 655 Change Management API. However, work order based change management is not considered to be a real-time process and incurs delay based on the SLAs agreed. For the Service Control requirements, which are mostly real-time in nature, TMF 655 may not be appropriate. The selection of appropriate API will be based on directions by EUAG architecture subcommittee. Interlude Related Work Items in MEFFollowing documents give details of the current work items being developed as part of MEF Interlude. Note: To be verified by Mehmet Toy
|
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Standardization Work
Opensource (including ONAP) Work
|
Expand | ||
---|---|---|
| ||
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 OSullivan
Following are some of the shortcomings in the current capabilities
|
Expand | ||
---|---|---|
| ||
This is a draft . To be updated later 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 onthe interaction between a Service Provider and Partner(s) Business Cases
Operational Use Cases
Interlude specific considerations
Best Practices and Standard Alignment
|
Expand | ||
---|---|---|
| ||
Architecture Subcommittee
Modeling Subcommittee
Security Subcommittee
Project team input
|
Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Component Specific Requirements (To be elaborated in detail later)
|
Expand | ||||||
---|---|---|---|---|---|---|
| ||||||
Operational Threads SONATA and Interlude with ONAP Components - Draft for Discussion Service On-boarding Service Creation On-Demand Service Control | ||||||
Expand | ||||||
| ||||||
Characteristic | ETSI | MEF | TMF | NGMN | ONF | IETF |
Use Case | NFVIaaS | Access E-Line + MEF-62 (May 2018) | NaaS | 5G Slicing | Inter Cluster ONOS Network Application (Collaboration withONOS) | Mainly transport network traffic engineering based on the multi-domain path computation |
Focus Area | Federation across MANO (virtualization domain) and ZSM Management Domains | Service Orchestration Function Federation – Focus on Service Layer | ODA : Autonomic Management interoperability across AD or Operational Domain interoperability – Focus on Service Layer | Slicing Management function interoperability, resource, and service Layer interoperability | •Cross Stratum Orchestration – end-to-end orchestration, abstraction and resource optimization across different SDN Controllers serving specific domains. | ACTN (Abstraction and Control of Traffic Engineered Networks ): Coordination of network resources across multiple independent networks, multiple technology layers, SDN & Non-SDN, Network abstraction, Network Slicing |
Scope | Interaction between MANO instances in different administrative domains , interaction across management domain in ZSM | Interaction between SOF function between operator and partner domains in LSO architecture | Interaction between Operational Domains through TMF Open API, Interaction between autonomic management functions | Interoperability between Slice management functions , service and resource layers | Orchestration of connectivity service that includes resources from several different domains, Coordinate service activation , monitor ongoing service | Multi-domain coordination, Network abstraction, Customer request mapping, virtual service coordination | Standard Interfaces/Reference points | Define a new Or-Or interface for inter orchestrator federation | MEF Interlude Reference point | Open API for inter-domain interaction – specifically TMF 641, 640, 645, 656, 653, 677, 633 | None | MPI – Interface between Multi-domain network controller and provisioning network controller – use NetConf Yang |
Relevance in ONAP | Interaction between NFVOs across Administrative domains assumingCatalogueis synchronized – ETSI Os-Ma or Or-Or interface | Interaction between SOF (ONAP Ext-API + SO) in two administrative domains through TMF APIs | Mostly Open API for interaction across Administrative Domains | General vision on Slicing across multiple domains | View on interaction between Orchestration and Controller functions across administrative domains. Use of Yang Models and TAPI | View on the interaction between Controllers in multiple administrative domains. May not be relevant for Ext-API but may be useful for ONAP in general |
Characteristic | OSM | ONAP | 5GEx | |||
Use Case | No specific use case | CCVPN | Many (NFVIaaS, VNFaaS, SlicingaaS etc) | |||
Focus Area | Interoperability between functional blocks across different domains | Federation across two operators ONAP instances for Service instantiation enabled through Ext-API | Federation in a multi-domain multi-layer orchestration scenario | |||
Scope | Interoperability between federated Functional blocks at different layers – i.e SO and RO, SO and SO etc. | Interoperability between Orchestration function and Ext-API across operator domains | Covers federation across multiple layers including business, orchestration and resource layers | |||
Standard Interfaces/Reference points | No standard interfaces, but SO expose SOL005 interfaces as of Release 3 | TMF 641 exposed by Ext-API | At NFVO layer 5GEx suggests the ETSI MANO specific interfaces, At RO layer, suggests NetConf/Yang | |||
Expand | ||||||
| ||||||
Expand | ||||||
| ||||||
Expand | ||||||
| ||||||
External API Requirements for supporting Inter-Provider API
|
Expand | ||
---|---|---|
| ||
Requirements Study how we can control modification requested at Interlude level – they are at least 2 subtopics there:
Dependency on other projects |
...