Use Case Authors:

China Mobile, Huawei, VDF, ZTE, VMWare

NOTE: More participants are welcome.


Description:

Business Driver:

It is the general demand for big Operators such as CMCC and Vodafone to build high-bandwidth, flat and super high-speed OTN (Optical Transport Network) facing with the transition to digital economy and information-based society. They also want to provide  a high-speed, flexible and intelligent service for high-value customers, and an instant and flexible VPN service for SMB companies. 

Furthermore, Operators want to be able to offer International end-to-end services to their Enterprise Customers. The ability to collaborate and interwork across Carriers is of paramount importance in such scenarios.

The current SOTN has some obvious disadvantages, such as:

Also, there are urgent demands for:

Considering the above aspects, we plan to make a combination of SOTN and ONAP in virtue of the strong orchestration ability of ONAP, which is called CCVPN(Cross Domain and Cross Layer VPN), to realize a unified management and scheduling of resource and services, and also to deploy services automatically. OTN super controller can be realized as a module of ONAP(SDN-C). In this way, multi-domain cooperation is achieved as well as resource and service automatically providing.
In this use case, our focus is not only restricted to resource, but also services from end to end perspective. Scenarios includes 'SOTN only', SD-WAN and end-to-end cross Carrier international private line creation. Priorities are described in the following sections.

Function specifications include:

  1. Physical network onboarding in ONAP 
  2. Cross-domain orchestration (multiple physical networks) : include route calculation based on abstract topology
  3. Cross operator end-to-end service provisioning
  4. Closed-loop reroute for Cross-domain service

 Priorities in the whole plan:

Action Phases:

Specific sub-use cases are:

Overall Topology Diagram

Work Flows 

Phase1:


Short description

Following a successful ONAP deployment, Customers can order CCVPN services via a customer self-service portal. ONAP orchestrator will forward requests to 3rd party SOTN Controller upon successful check of service request and OTN resource state. Afterwards, a private channel is built. Domain controller will finish resource configuration on the basis of ONAP request.

For The CCVPN use case, 4 services are designed: SOTN VPN Infra Service, SD-WAN VPN Infra Service, Site DC Service , Site Enterprise Service.

One CCVPN scenario, may contain one SOTN VPN Infra Service, more than one SD-WAN VPN Infra Services, more than one Site DC Services, more than one Site Enterprise Services. Likewise, each  SD-WAN VPN Infra Service can attach more than one site.



  1. Topology Notification flow


    1. Register the 3rd party SOTN Controller to ESR.
    2. ESR trigger a 3rd Controller registered event to Dmaap.
    3. SDNC subscribe the event and this event notified .
    4. SDNC synchronize the topology from 3rd SOTN controller.
    5. SDNC analyse the data from 3rd SDN controller.  Get the nodes, links, terminal points of the topology.
    6. SDNC call A&AI to create the nodes, links terminal points to save the topology.
          Note: For multi 3rd SDN controllers, there will be several topologies notified.  The links across the domain topology should be discovered or created by ONAP. 

  2. SOTN VPN Infra Service Deploy Flow

3. SD-WAN VPN Infra Service Deploy Flow

3. Site Enterprise Service Deploy Flow

     

4. Site DC Service Deploy Flow



5. Closed Loop Flow 


5.1 DCAE Flow in Close Loop (with better diagram later on)

      

  1. RestConf Collector (RC)subscribes for remote failure alarm to SOTN Controller (SC) 
  2. RC requests to set up a long term tunnel with the 3rd party SC
  3. SC responses with OK upon successful tunnel setting
  4. SC pushes service route status data to the collector
  5. RC receives alarm data, converts it into JSON format and publishes on DMAAP with topic of ROUTE_ALARM_OUTPUT
  6. UVA consumes the alarm message
  7. UVA requests the RestConf2VES mapping
  8. UVA converts json alarm into VES  event
  9. UVA publishes the VES event on DMAAP for further correlation   

6. Service Design Flow



Platform Requirements

PNF Onboard (abstract topology)

Deploy Artifacts for physical network

Cross-Operators interwork (MEF etc.)

Tenant management

Project Impact

PHASE1:

PHASE2+:

Priorities (TBD)

PNF:

CPE: customer premises equipment, the equipment located at an end-user's premises, can be configure or managed via CLI or controller.

Physical network: a SDN network that can provide E2E MEF EPL service to ONAP, it can be multi-layer network, an 3rd controller can separate the control plane and the forward plane, and will handle the instantiation and LCM of EPL under the command from ONAP, and provide abstract topology to ONAP to facility the homing calculation.

Location

PNFs

Intended Provider

PNF CSAR

Site

CPE

Huawei, ZTE


Physical network

OTN network element

Huawei, ZTE






VNF:

VNF: vCPE or similar VNF/APP that need to deploy in site (the enterprise or the Datacenter).

NFVI+VIM: provide infrastructure to run VNF/app.

Location

VNFs

Intended Provider

VNF CSAR

enterprise

vCPE

Huawei?ZTE





Datacenter









NFVI+VIM:

Utilize vendors NFVI+VIMs in the ONAP platform.

Location

NFVI+VIMs

Intended Provider

Note

Datacenter


Huaiwei, VMWare






Work Commitment

< identify who is committing to work on this use case and on which part>

Work Item

ONAP Member Committed to work on CCVPN

Modeling

CMCC, VDF, Huawei, Verizon

SDC

Huawei

SO

Huawei

OOF

Huawei

SDN-C

CMCC, Huawei

UUI

CMCC, Huawei

DCAE

Huawei

VF-C

Huawei

A&AI

Huawei

External API

Huawei



Attachments: