Page History

Use Cases

Referring to the MEF 55 Operational Threads as documented here, there are two levels of interactions between service provider and partner - at 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