...

From an Operator's 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).  The ultimate goal of this use case is, by taking advantage of the strong orchestration ability of ONAP, to automatically create and deploy a cross operator, cross domain (SOTN + SD-WAN), cross layer (L1, L2, L3) end to end VPN and update the service dynamically.
Main functions in this use case include automatically design of end to end service, creation of end to end service, cross-domain resource cooperation, global rerouting.
We testified this possibility in C release and realized functions like topology discovery, simple service creation, as well as back-up link switch in closed loop.

Planning for Dublin (Not fully provided in Dublin Release, will be continued in Frankfurt Release)

In Casablanca, the basic CCVPN usecase demonstrated ONAP's capability in designing and creating an end-to-end VPN service across operator domains.

...

High Priority Extensions (enhancements) in Dublin release:

Multi-site to multi-site 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 create an E2E service with one service template by supporting inputs of multiple resources at the same time (instead of using multiple service templates one by one when creating an E2E service) 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 : Add or Delete a site 

...

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.

...

Specific sub-use cases / functional requirements

• Distributes Analytics as a Service 

Additional Extensions

• E-LAN Service (EP-LAN, EVP-LAN)
• Smart Disaster Recovery(DR) for NFV
• CCVPN Service Function Chain(SFC)
• Extension for L0/L1 (Dublin) - Proposal
  High level Work items identified for L0/L1 support
  
  1. Understand the SDC components already designed for CCVPN case and see what additions need to be added to support new resources required for exposing T-API based SIP(Service interface points) and SEP(Service end points) for end to end OTN service  - https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/CCVPN+Wan+Connection+Service+Design
  2. Work on populating A&AI with the info from T-API network model which can then be used as Resources for instantiating a service using the SDC design
  3. Work on creating a SDN-C plugin that can be used to Map T-API based APIs to SDN-C via directed graph which can then be used by components like SO and run time part of SDC to create the end to end service
  4. Work on getting the T-API compliant alarm notifications from thirdparty SDN controllers into DCAE and see how these can be mapped to existing VES collector and or new micro service which implements use case specific business logic to achieve closed loop scenarios like switching to alternate path based on faults or changing bandwidth etc..

...

Weekly Call Recording:

...

...

Implementation in Dublin Release: