You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »


This page is intended to capture the ongoing study and discussion in the Ext-API project related to the inter-CSP interaction enabled through the MEF interlude specification. This is related to the JIRA item planned in the Casablanca cycle. While it is essential to carry out a detailed study on the inter-provider interactions and overall impact on ONAP as a solution, the scope of this page will be limited to the impact on External API. Additionally, while the focus is on the MEF interlude specification, there is some good amount of work being done in many SDOs to address the scope of inter-provider management interactions - notably TMForum, ETSI, NGMN, ONF, IETF etc. It is worth noting the scope and outcome of these SDOs and analyze some best practices that ONAP can incorporate. It is also worthwhile to note how other opensource communities like OSM, 5GPPP/5GEx etc tackled this issue. Further, the page also captures the short term and long term requirements to support Interlude like inter-provider interaction.



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 as part of 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 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.


Standardization Work

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.
•ONF/ OIF: Multi-Domain Control as part of TAPI

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

Cross Stratum Orchestration CPI interface between CSO Controller and Domain Controller – TAPI


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

Opensource (including ONAP) Work

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


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 on interaction between a Service Provider and Partner(s)

Business Cases

  • NFaaS (Network Function as a Service)
  • NaaS /SD-WAN
  • SlicingaaS
  • MVNO Scenario
  • Connectivity as a Service 
  • NFVIaaS
  • Application as a Service (For Edge scenarios) 

Operational Use Cases


  • Dynamic Service Control
  • Query Service State
  • Update Service
  • Request Connectivity Service (across two Service interfaces)
  • Query Service Inventory
  • Receive Service Notification
  • Receive Service Performance Update
  • Initiate Service Test 

Interlude specific considerations


  • Layers of interaction, Separation of concerns: Whether to limit the interaction between SP and Partner through a specific layer - for example, Ext-API or support interactions across layer - i.e to support interaction between Ext-API in the Service Provider domain and SO or Controller in the Partner domain. What kind of APIs are used for such interactions?
  • Security: Securing the interaction between Service Provider and Partner based on a predefined contract and policy
  • Business contract - Policy: Business contract agreed between Service Provider and Partner that will govern the interactions
  • SLA Management: The components and method for monitoring and managing SLA including the closed control loop across service provider and partner domains
  • Inventory/State Management, Consistency Check, Identity mapping: How inventory across two domains are represented in respective domains, how it is reconciled and how the consistency is checked.
  • Interface/API – Reference Specification: What standard APIs to be supported over the Interlude reference point
  • Licenses: How licenses are controlled across SP and Partner domains, What are the impacts and associated fulfillment implications due to resource licenses.
  • Modelling impact: Interlude impact on Modelling work - especially the representation of Partner resources, reachability information, configuration.
  • Integration: Requirements for the integration between SP and Partner components via standard APIs, channels for event and performance data collection, reconciliation
  • Interoperability: Interaction between SP and Partner, with either one of them having an ONAP instance
  • ONAP Role: Assigning roles - such as master, slave to ONAP considering deployments at SP and Partner domains -specifically for coordination of end to end service orchestration and data collection.

Best Practices and Standard Alignment


  • ETSI GR NFV-IFA 028 V3.1.1 (2018-01)
  • ETSI ZSM
  • MEF LSO Interlude (link)
  • Contributions by Mehmet and Jack
  • TMF ODA
  • ONAP CCVPN Use Case
  • 5GPPP 5G-Ex Project

Requirements


 Study how we can control modification requested at Interlude level – they are at least 2 subtopics there:

    • Identify where the information could be managed within ONAP (in SDC ? have attribute change value and state change authorized at SOF-SOF interaction level ?)
    • Explore if External API can be used by internal ONAP Components as a proxy to talk to external Partner ( e.g. ONAP 1 SO call ONAP 1 ExtAPI, then ONAP 1 ExtAPI call ONAP 2 ExtAPI ) i.e. ONAP internal components can communicate securely internally, External API act as proxy to forward request ( e.g. Service Order ) to Partner ( maybe a Partners ONAP External API Framework ). 
    • Define the API (resource model) that allow the system to request ‘authorized’ service modification (Policy API ?)

Dependency on other projects


Links to other SDO and Opensource Work

  • No labels