Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

NOTE: More participants are welcome.

Overview

Business Requirement

1.

2.

3.

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.

...

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.

...

ProjectPTLNumber of Required ResourcesCommitted Resources (Names/Company)
A&AI


SDC


0.5 from ZTE Peng He , 1 from Vodafone Prabhu Balan

DCAE


1 from CMCC Guobiao Mo 1 from VMWare xinhuili

Modeling


(0.5 from CMCC LIN MENG , (0.5 from Huawei Seshu Kumar Mudiganti , 0.5 from ZTE Zhuoyao Huang ,0.5 from China Telecom Huang ZongHe , 0.5 from Fujitsu ravi rao )

External API


1 from Vodafone emmanuel sarris

SO


(1.5 from CMCC Zhang Min , 1 from Huawei Seshu Kumar Mudiganti , 0.5 from ZTE Zhuoyao Huang 2 from Vodafone Davide Cherubini Razanne Abu-Aisheh , 1 from Fujitsu ravi rao )

OOFSarat Puthenpura


TBD
SDN-C

(1 from HuaweiGaurav Agrawal , 1 from ZTE Zhuoyao Huang , 0.5 from Fujitsu ravi rao )

PolicyPamela Dragosh
0.5 from Huawei jun zhou
VFC
Holmes
0.5 from Huawei jun zhou
VNFSDKWeitao Gao

1 from VMWare xinhuili

MCloudBin Yang

1 from VMWare xinhuili , 0.2 from ChinaTelecom Huang ZongHe

UUITao Shen

Weekly Call Recording:

...




...

Implementation in Dublin Release: