Use Case Authors:

China Mobile, Vodafone, Huawei, ZTE, VMWare, Intel, WindRiver, China Telecom, Fujitsu, Lenovo

NOTE: More participants are welcome.

Overview

Recap for Casablanca 

In Casablanca release, we propose CCVPN(Cross Domain and Cross Layer VPN) use case, in which scenario if a customer wants to set up a VPN from Beijing to London, we can use ONAP to stretch such a VPN service that is cross operator, cross domain and cross layer.
cross operator: the VPN service could be stretched between two ONAPs.
cross domain: a VPN service is cross diffrent OTN domains which is controlled by different 3rd parties
cross layer: the VPN service can be l1,l2,l3 or any composition of these layers, eg: a VPN service that is cross l2 and l3

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.

In realistic CCVPN service deployment, the customer may want to add two sites in Shanghai and Wuhan onto the original service due to their business needs. Customers also have the need to do some modifications on the existing service, eg: to change the bandwidth or to build up a vFW in the VPN.

Therefore, in Dublin release, we would like to extend the scenario of CCVPN use case to include enhancements in the following aspects:

1. Service Change Management, to allow the customer to dynamically add more branch sites or value-added services (e.g. vFW) on demand to individual site onto their running CCVPN service instances.

2. Intelligent Bandwidth on Demand, to allow third party analytics applications to trigger ONAP close loop for adjusting the running CCVPN service instances (e.g. the bandwidth between specified sites).

Open

User Stories

Service Provisioning Categories

In Dublin, CCVPN assumes the SP provides two types of service functions to its enterprise customer for selection, including: 

• Basic VPN service between sites, where the number of sites and the bandwidth among them could be adjusted dynamically.

• Value-Added services which could be part of the intial service procurement before its creation or added on demand to a running service instance.

To best represent the common requirements for potentially huge number of value-added services that might be interesting to the cutomer, two are selected for CCVPN demonstration, including 

• vFW, which demonstrate the requirements for chaining another traffic handling function into the user plane, and

• intelligent surveillance application, which demonstrate the requirement for distributed deployment architecture in the user plane and also the close loop automation integration in the control plane.

Network Topology Assumptions

A network hierachy of at least two layering of DCs  are assumed in this usecase, including:

• the core DC, where the ONAP central is running, and

• the edge DCs, where the virtual functions/applications that are deployed near the customer's sites are running.

For the intelligent surveillance application, which is a specific value-added service, once initialized,

• its centralized monitoring portal is deployed at the edge DC near the enterprise HQ, and

• the AI applications for collecting both the vioce/video monitoring and anormaly recognition, are deployed in a distributed fashion to the edge DCs that are near the specific site(s) under surveillance.

User Stories

Two kinds of people are assumed in this case:

1) Customer: Owner of a service, people who want to place a CCVPN service order, change the order and pay money for the service. They have less or no knowledge of technology details. 

2)User: Executor of instantiating, monitoring and managing a CCVPN service. Detailed CCVPN service parameters are provided by these people who are experts in how to run a CCVPN service and know all the detailed inputs well.

1. Service Procurement (SP)

   The enterprise HQ may want to order a VPN stretch between two or more branch sites, they may also want other value added services bind with the VPN service. A customer facing portal is provided under this condition so that a customer can choose which sites to set the VPN service and combine what kind of  value added service with the VPN service, as well as provide other customized needs of the service like the bindwidth and duration without knowing the deployment details and VPN parameters. We call this process as service procurement and a service order is placed at this phase.

2. Service Instantiation (SI)

   After the service order is obtained, another page will pop out for users to finish other detailed inputs of CCVPN parameters so that a  CCVPN service can be instantiated and deployed by ONAP.

3. Service Change (SC)

   Besides setting up a VPN service between multiple sites, customer may also have the needs to add other sites or add a new value-aadded service onto the existing VPN service according to their demands.

   1. SC1: Adding a new site

      Customer chooses "Change Service" button in customer portal, and selects the sites to be added. After the order change is finished, the changed order will be passed to user portal to inform the user. Then, users will modify the sites information  as well as other service input parameters and command ONAP to do the service change.

   2. SC2: Adding a new value-added service 

      Customer chooses "Change Service" button in customer portal, and selects the value-added service to be added. After the order change is finished, the changed order will be passed to user portal to inform the user. Then, user will add  related parameters and command ONAP to do the service change.

4.  Close Loop Intelligent Suveillance (IS)

   After user subscribes the AI apps, AI apps on the edge can analysis data collected by camera or other security detector. Once there is an alarm,  the original alarm data will be transferred to Ves Collector and DMaaP will translate the data, Holmes will send the event to Policy to trigger the responding action to adjust the bandwidth in close loop.

Open

Gap Anaysis and Functional Requirements

Implementation Proposals  

Design Time Workflows

• VNF onboarding

• Service Template Design

• Service Change Workflow Design

• Bandwidth on Demand Policy Design 

Run Time Sequence Diagram

• Service Procurement (SP)

  Open

  

• Service Instantiation (SI)

• Open

  

• Service Change (SC)

  1. SC1: Adding a new site

     Open

     

  2. SC2: Adding a new value-added service 

     Open

     

• Close loop Intelligent Suveillance (IS)

Open

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. 

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.

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.

Besides the change of service components like adding or deleting the sites, we also have the needs to add a VNF like vFW in the service or change the inputs parameters of an existing service.

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://lf-onap.atlassian.net/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..

Priorities for Dublin

(Initial assessment)

High Priority

Medium Priority

Low Priority

*feature already proposed for Dublin release

Resource Requirements (per Project)

Implementation in Dublin Release: