Page History

Operational Threads

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

• Serviceability Enquiry and Quote Request/Response
• OPTION A: Product Order Request/Response
• OPTION B: Product Order for interfaces, network functions or connectivity
  

Interlude (SOF<->SOF)

• OPTION A: Service Request for configuration of interfaces, network functions or connectivity
• Connectivity and Performance Testing for the Partner Service
• Reconfigure Partner Service
• Request Performance and Fault Information for Partner Service

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 MEF55

Referring 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

• Scheduling, assigning and coordinating service control related activities;
• Undertaking necessary tracking of the execution process of service control requests;
• Adding additional information to an existing service control request under execution;
• Modifying information in an existing service control request under execution;
• Modifying the service control request status, and indicating completion of a service control request;
• Canceling a service control request; - Monitoring the jeopardy status of service control requests, and escalating service control requests as necessary;
• Instantiating, when appropriate, an event for the billing system to capture the policy-constrained change.

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 Interactions

The interactions factored in the MEF Interlude Reference point are as follows

• Service Provider controls aspects of the Service within the Partner domain (on behalf of the Customer) by requesting changes to dynamic parameters as permitted by service policies.
• Service Provider queries the operational state of the Service.
• Service Provider requests change to the administrative state of a service or service component (e.g. Service Interface)
• Service Provider requests update to defaulted service parameters which are allowed to be customized (policy-controlled)
• Service Provider requests the creation of connectivity between two Service Interfaces as permitted by established business arrangement.
• Service Provider provider queries the Partner's Service Inventory for services provided by the Partner to the Service Provider.
• Service Provider receives Service specific event notifications from the Partner.
• Service Provider receives Service specific performance information from the Partner.
• Service Provider requests test initiation and receive test results from the Partner.

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

• Service Provider Queries the Service Catalogue for the offered Services by Partner
• Service Provider places Service Order for a Service offered by Partner

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. Additionally, 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 right API will be based on directions by EUAG architecture subcommittee.

As per the guidelines in the document here, interlude should be used for

• Service configuration
• Service activation, de-activation, modification, deletion
• Service testing
• Service assurance

Out of this service configuration scope should include

• Setting Schedule for Configuration
• Configuration of User Interfaces
• Configuration of Connection
• Configuration of Connection End Points
• Configuration of Redundancy

Interlude Related Work Items in MEF

Following documents give details of the current work items being developed as part of MEF Interlude.

Note: To be verified by Mehmet Toy

• Interlude Guidelines: Gives the high-level scope of Interlude
• Access E-Line CIR Change Process Flow: Highlights the interactions between SP and Partner for CIR change for a provisioned e-line service over the interlude reference point leveraging the service configuration.
• Access E-Line Service Information Model: Based on MEF MCM (Mef Core Model), with extensions to be used for elastic service levels and service schedule
• Business Requirements and Use Cases for Access E-Line Service Control
• MEF LSO Interlude Activation API

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

• 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 shortcomings in the current capabilities

• Services need to be independently designed and distributed on either both 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)

Operator Input

• Do we need to consider intraoperator multi-administrative domain interaction – i.e communication across different instances of domain orchestrators (ONAP or non-ONAP) belonging to the same operator?
• Do we need to limit the scope of Interlude to Service Control, Activation, and Configuration or include Service Order Management?
• Do we need to come up with ONAP specific terminology? Different SDOs follow different terminology e.g. operator interoperability, domain interoperability, administrative system interoperability etc. ?
• Catalogue and Inventory Management – Strategy for 1) onboarding the catalog with service specification across interdomain boundaries 2) Reconciliation and aggregation of inventory at each domain – Pull vs Push model
• Service Model Impact: Service hierarchy in the Service model – i.e Composite or Nested Service, Constituent Service – How the service model is decomposed and distributed to operator and partner domains? Any pattern to follow? Or based on request attributes?
• Cross-layer access requirement for multi-domain interaction for example Orchestration layer of SP need to interact with VIM of Partner for resource instantiation – Is this model valid (MLPOC as per ETSI IFA028 )
• Federation vs Delegation
• Federation Actors and Roles: What type of provider roles we should consider – (NGMN Actor Roles ? 5GEx Actor Roles etc – Infrastructure provider, Connectivity SP, Partner SP, Master/Slave), Do we also need to consider different layers of partners – infrastructure, connectivity etc.
• Use Cases: What use cases we should consider for the interlude specification? Generic Operational use cases (Service activation, query etc)  or Specific Business use case ? (NaaS, NFaaS, Access E-Line etc) – Short term and Long Term Target?
• Consideration for interaction between ONAP and non-ONAP (Legacy) Management system across operator domains
• Need for including the Business layer interactions within the scope of interlude (for example dependency on Service Policy)
• Strategy for closed-loop control (Assurance) – Who will manage? Partner managed or SP managed
• Resiliency requirements for inter-operator management connectivity – Failover mechanisms
• Do we need to consider interdependency of Interlude and Legato/Sonata interface? (for example contract) 
• Service Impact Assessment
• Need for Service Change Management
• Dynamic or Static workflows to be supported
• Optimization framework dependency
• Use Cases: What use cases we should consider for the interlude specification? Generic Operational use cases (Service activation, query etc)  or Specific Business use case ? (NaaS, NFaaS, Access E-Line etc) – Short term and Long Term Target?
• Consideration for interaction between ONAP and non-ONAP (Legacy) Management system across operator domains
• Strategy for closed-loop control (Assurance) – Who will manage? Partner managed or SP managed
• Resiliency requirements for inter-operator management connectivity – Failover mechanisms
• Do we need to consider interdependency of Interlude and Legato/Sonata interface? (for example contract) 
• Service Impact Assessment - Need for doing a Service impact analysis before any operation over interlude
• Need for Service Change Management: Interlude operations to be initiated as work order through a Change management API (e.g. TMF 655) - Is this the practical mode of operation? Or expect a more dynamic service control operation ?
• Dynamic or Static workflows to be supported to accommodate Interlude operations (SO and beyond)

Architecture Subcommittee

• Onboarding and distribution model for SP and Partner Service Descriptors - Controlled by separate SDC instances or by common SDC instance.
• Catalogue and Inventory Management – Strategy for 1) onboarding the catalog with service specification across interdomain boundaries 2) Reconciliation and aggregation of inventory at each domain – Pull vs Push model
• ONAP specific terminology: Different SDOs follow different terminology e.g. operator interoperability, domain interoperability, administrative system interoperability etc.
• Cross-layer interaction requirement and the need to accomodate this as part of interlude scope: for example OOF layer of SP need to interact with Multi-VIM of Partner for resource utilization, SDNC of partner sharing data to DCAE of SP (both not via Ext-API interlude but inter-component APIs) – Is this model valid (MLPOC as per ETSI IFA028 )
• Federation vs Delegation
• Federation actors and Roles : What type of provider roles we should consider ? Infrastructure provider, Connectivity SP, Partner SP, Master/Slave), Do we also need to consider different layers of partners – infrastructure, connectivity etc.
• Need for including the Business layer interactions within the scope of interlude (for example dependency on Service Policy), Service Creation (in the absence of Business Application)
  
  

Modeling Subcommittee

• Service Model Impact: Service hierarchy in the Service model – i.e Composite or Nested Service, Constituent Service – How the service model is decomposed and distributed to operator and partner domains? Any pattern to follow? Or based on request attributes?
• Representation of Partner Service and Resources , Partner Registration data, Policy, Service associations between SP and Partner in Inventory
• Use of Allotted Network Function vs SPPartner for representing Partner Service
• Data Model Alignment for Ext-API : TMF vs MEF vs ONAP runtime model

Project team input

• SO: Plan for supporting Service configuration, Service change - What REST APIs to use PUT or PATCH of Service or a dedicated action
• Policy: Representation of confguration policies for cross operator interaction, representation of constraints for scheduling operations on Interlude
• SDC : Modelling and managing Partner services, service access points, distribution of service
• A&AI : Representation of partner resources and servicesPolicy Dependency