Use Case Authors:

Vodafone, China Mobile

NOTE: More participants are welcome.

Description

CCVPN Use Case extension for Dublin, includes Service Creation and Modification using the concepts of Unified and Composite Services. 

Furthermore, from an Operator perspective, it is important to introduce the capability to manage the performance of the CCVPN End-to-End service (especially when it spans across different Operators).

Current Situation

In Casablanca release, the CCVPN service is created by mean of separate multiple Service Orders via TMF 641, with one service orderItem for each of the services that make up the CCVPN connectivity Service. (Note -the UUI in Casablanca makes separate calls to SO, i.e. does decomposition but without Service Orders)

The complete removal of the CCVPN Service would involve the Portal/UUI making multiple separate Service Orders with one orderItem, each with a ‘delete’ action. This because there is no E2E Service Instance that corresponds to the full CCVPN Service. 

Proposed enhancements for Dublin release

Service Model Optimization

In Casablanca release, the ability of SDC‘s service template doesn’t support multiple inputs of different instances, which leads to the situation that we need to design site and VPN Infra in separate service templates.

In R3, Modeling Subcommittee accepts the concepts of 'Atomic' and 'Composite', in which CCVPN is a strong evidence of composite service.

The needs of providing a real end to end service in ONAP arouse the demands for designing a composite service in one service template.

Our targeted solution to CCVPN model in Dublin release is:

CCVPN service is composed of two kinds of atomic service: SD-WAN service and SOTN service Atomic service consists of serveral composite resources, like site and VPN-Infra.

To support the composite service, there should be some improvements in implementation.

1. In service template, It should support the list structure of inputs so that a service can have multiple inputs of resources.

     2. SO should allow service updating work flow.

Service Creation

In an ideal implementation, the Portal shall create a single Service Order via TMF 641, with multiple service orderItem(s) for each of the services that make up the CCVPN Service.

• SDC should support Composite Services creation and SO should have the capability to decompose and (eventually) delegate the nested Services.
• A&AI should maintain composite End-to-End Service Instance for CCVPN.
• Parameters for all services can be passed as one composite orderItem to External API. 

Service Change

A CCVPN End-to-End Service Change (e.g., bandwidth change), should be either triggered by the portal (as TMF 641 single service orderItem with ACTION ‘change’) or by a policy implemented to guarantee that SLS is met.

Similarly to the Service Creation, this change (or modification) should be handled by SO, which decomposes the Service Change and sends it, via External API, to the other Operator(s) in the form of PATCH service.

SO should offer Service Modification API and associated workflows to interact with SDN-C, A&AI and External API to make the required service adjustments.

Finally, SDC must be able to model the LCM Operation/Interfaces for modifications allowed on the CCVPN Service (e.g., AdjustBandwidth) so that the modification capability can be exposed through the Service Catalog.

Service OAM

The Service OAMs (Fault & Performance Management) are used to guarantee the SLA objectives. Initial focus for CCVPN Dublin Release should be on modeling SOAM-PM for Composite Services in the Service Catalog.

Specific sub-use cases 

• E-LAN Service (EP-LAN, EVP-LAN)

Priorities for Dublin

(Initial assessment)

*feature already proposed for Dublin release