Use Case Authors:
China Mobile, Vodafone, Huawei, ZTE, VMWare, Intel, WindRiver, China Telecom, Fujitsu, Lenovo
NOTE: More participants are welcome.
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.
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:
In Dublin, CCVPN assumes the SP provides two types of service functions to its enterprise customer for selection, including:
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
A network hierachy of at least two layering of DCs are assumed in this usecase, including:
For the intelligent surveillance application, which is a specific value-added service, once initialized,
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.
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.
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.
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
(Initial assessment)
High Priority
Feature | Author | Impacted Project | Note |
---|---|---|---|
SD-WAN Multi-site to Multi-Site Service Creation | ChinaMobile,Huawei,ZTE | SDC, SO, A&AI, OOF,UUI, ESR, Modeling,SDN-C |
|
Service Change: Add or Delete a Site | ChinaMobile, Vodafone, Huawei, ZTE, | SO, SDN-C, A&AI, VFC, MCloud, UUI, ESR |
|
Close loop Intelligent Surveillance | ChinaMobile, Huawei | DCAE(Holmes), Policy, SDN-C |
|
Medium Priority
Feature | Author | Impacted Project | Note |
---|---|---|---|
E-Lan Service | Vodafone | SDC, SO, SDN-C,External API, A&AI | |
Value-added Function | AI Apps: China Mobile | SDC, SO, VFC, MCloud, A&AI | |
SFC: China Telecom | SDC, SO, VFC, MCloud, A&AI | ||
Smart Disaster Recovery | VMWare, ChinaMobile | Modeling,SO/VFC, OOF, DCAE, A&AI |
Low Priority
Feature | Author | Impacted Project | Note |
---|---|---|---|
Extension for L0/L1 | Fujitsu | SDN-C, A&AI |
*feature already proposed for Dublin release
Project | PTL | Number of Required Resources | Committed 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 ) | ||
OOF | Sarat Puthenpura | TBD | |
SDN-C | (1 from HuaweiGaurav Agrawal , 1 from ZTE Zhuoyao Huang , 0.5 from Fujitsu ravi rao ) | ||
Policy | Pamela Dragosh | 0.5 from Huawei jun zhou | |
VFC | |||
Holmes | 0.5 from Huawei jun zhou | ||
VNFSDK | Weitao Gao | 1 from VMWare xinhuili | |
MCloud | Bin Yang | 1 from VMWare xinhuili , 0.2 from ChinaTelecom Huang ZongHe | |
UUI | Tao Shen |