...

It is the general demand for big operators 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 privide  a 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:

...

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-VAN and international WAN and end-to-end cross Carrier international private line . But at present, 'SOTN only' is at our 1 priority, which is going to be executed in Phase1 in the followingcreation. Priorities are described in the following sections.

Function specifications include:

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

 Priorities in the whole plan:

• Priority1Priority 1: Combine SOTN with ONAP, to manage and orchestrate services automatically.
• Priority2Priority 2:   Cross-domain E2E Orchestration.
• Priority3:  SD-WAN controller is added in this phase to realize cross Layer VPN services.
• Priority4:  Build up Priority 3: Create the international private line , to realize the connection between ONAPs(ONAP instances interconnection and interwork).
  
• Priority 4:  SD-WAN controller is added to realize cross Layer VPN services.

Action Phases:

• Phase1: SOTN Orchestration
  • Single Domain
  • Multiple Domains
• Phase2: Cross Carrier Service Creation (ONAP interworking)
• Phase 3: + SD-WAN Phase2: ONAPs Connectionservice Creation
  
  

Specific sub-use cases are:

• Service onboardingand resource on-boarding
• Service configuration
• Service termination 
• Self service addaption adaptation (Bandwidth on demand  to be added)
• Auto-scaling based on  fault and performance (stretch goal)
• fault detection and auto-healing (stretch goal)
• data correlation and analytics (stretch goal)

Overall Topology Diagram

Work Flows 

Phase1:

Brief

Short description

...

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

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

One CCVPN scenario, can contains  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. And Each  SDLikewise, each  SD-WAN VPN Infra Service can attach more than one site.

...

• 1. SDC/CLAMP Portal design and activate policy.
• 2. SDC/CLAMP config and activate the policy.
• 3. SDC/CLAMP distribute the DCAE config.
• 4. SDC/CLMAP distribute the alarm correlation rules to Holmes.
• 5. 3rd party SOTN controller report link down alarm to DCAE
• 6. DCAE will do data cleaning and filtering for the alarms
• 7. DCAEk keep track the datas.
• 8. Holmes do analysis for the alarms.
• 9. Holmes notify the reroute event.
• 10. Policy matching the reroute rules.
• 11. Policy call SO to delete the old services and create the new services. For the creation flow, a variable route will be recalculated.

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

      Image Added

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

• 1. Design the service in SDC portal
• 2. SDC distribute the service information to SO
• 3. SDC distribute the service network information to SDNC
• 4. SDC distribute the service model information to AAI
• 5. SDC distribute the service VNF information to VFC/APPC.

...