CCVPN (Cross Domain and Cross Layer VPN)

Sevice used for CCVPN


Cross-domain, cross-layer VPN (CCVPN) is one of the use cases of the ONAP Casablanca release. This release demonstrates cross-operator ONAP orchestration and interoperability with third party SDN controllers and enables cross-domain, cross-layer and cross-operator service creation and assurance.

The demonstration includes two ONAP instances, one deployed by Vodafone and one by China Mobile, both of which orchestrate the respective operator underlay OTN networks and overlay SD-WAN networks and peer to each other for cross-operator VPN service delivery.

The CCVPN Use Case Wiki Page can be found here:

The projects covered by this use case include: SDC, A&AI, UUI, SO, SDNC, OOF, Policy, DCAE(Holmes), External API, MSB

How to Use

Design time SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps can be found here: WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ):

Run Time: All opertion will be triggerd by UUI, inlcuding service creation and termination, link management and topology network display.

More details can be fonud here:

Test Status and Plans

All test case covered by this use case:

And the test status for Casablanca release can be found:

The test status for Casablanca Maintenance release can be found:

Known Issues and Resolutions for Casablanca Maintenance Release

  1. Site service distribution error, this is caused by SDC-parser and have been solved in SDC Parser 1.4.63, see the JIRA on
  2. Csar distribution write SO DB error, this have been solved
  3. SO haven’t register in msb automatically, see the JIRA on and follow the instruction on comments section to register SO API in MSB manually.
  4. UUI call SO to create service, SO V3 API can work, but V5 can’t work, so in casablanca relase please use SO V3 and V5 will be provided in Dublin release, JIRA is created
  5. SO can not get “operationType” in CreateSDNCNetworkResourece and ActivateSDNCNetworkResource. This can be tracked on
  6. Sdc Controller Error while CSAR distribution. This can be tracked on

The known Issue list which solution will be move to Dublin release

Known Issues and Resolutions for Casablanca Release

  1. AAI-1923. Link Management, UUI can’t delete the link to external onap otn domain.

For the manual steps provided by A&AI team, we should follow the steps as follow the only way to delete is using the forceDeleteTool shell script in the graphadmin container. First we will need to find the vertex id, you should be able to get the id by making the following GET request.

GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete/esr-system-info/test-esr-system-info-id-val-0?format=raw


“results”: [ { “id”: “20624”, “node-type”: “pserver”, “url”: “/aai/v13/cloud-infrastructure/pservers/pserver/pserverid14503-as988q”, “properties”: { } } ] }

Same goes for the ext-aai-network:

GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete?format=raw

Retrieve the id from the above output as that will be the vertex id that you want to remove.

Run the following command multiple times for both the esr-system-info and ext-aai-network:

kubectl exec -it $(kubectl get pods -lapp=aai-graphadmin -n onap –template ‘range”n”end’ | head -1) -n onap gosu aaiadmin /opt/app/aai-graphadmin/scripts/ -action DELETE_NODE -userId YOUR_ID_ANY_VALUE -vertexId VERTEX_ID

From the above, remove the YOUR_ID_ANY_VALUE and VERTEX_ID with your info.

  1. SDC-1955. Site service Distribution

To overcome the Service distribution, the SO catalog has to be populated with the model information of the services and resources. a) Refering to the Csar that is generated in the SDC designed as per the detailes mentioned in the below link: b) Download the Csar from SDC thus generated. c) copy the csar to SO sdc controller pod and bpmn pod

kubectl -n onap get pod|grep so kubectl -n onap exec -it dev-so-so-sdc-controller-c949f5fbd-qhfbl /bin/sh

mkdir null/ASDC mkdir null/ASDC/1 kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar dev-so-so-bpmn-infra-58796498cf-6pzmz:null/ASDC/1/service-Sdwanvpninfraservice-csar.csar kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar dev-so-so-bpmn-infra-58796498cf-6pzmz:ASDC/1/service-Sdwanvpninfraservice-csar.csar

  1. populate model information to SO db

The same would also be applicable for the integration of the client to create the service and get the details. Currently the testing has been performed using the postman calls to the corresponding APIs.

  1. SDC-1955 & SDC-1958. Site serivce parsing Error

UUI: stored the csar which created based on beijing release under a fixed directory, If site serive can’t parsed by SDC tosca parser, UUI will parse this default csar and get the input parameter a) Make an available csar file for CCVPN use case. b) Replace uuid of available files with what existing in SDC. c) Put available csar files in UUI local path (/home/uui).

  1. SO docker branch 1.3.5 has fixes for the issues 1SO-1248.
After SDC distribution success, copy all csar files from so-sdc-controller:
connect to so-sdc-controller( eg: kubectl.exe exec -it -n onap dev-so-so-sdc-controller-77df99bbc9-stqdz /bin/sh ) find out all csar files ( eg: find / -name ‘*.csar’ ) the csar files should be in this path: /app/null/ASDC/ ( eg: /app/null/ASDC/1/service-Sotnvpninfraservice-csar.csar ) exit from the so-sdc-controller ( eg: exit ) copy all csar files to local derectory ( eg: kubectl.exe cp onap/dev-so-so-sdc-controller-6dfdbff76c-64nf9:/app/null/ASDC/tmp/service-DemoService-csar.csar service-DemoService-csar.csar -c so-sdc-controller )
Copy csar files, which got from so-sdc-controller, to so-bpmn-infra
connect to so-bpmn-infra ( eg: kubectl.exe -n onap exec -it dev-so-so-bpmn-infra-54db5cd955-h7f5s -c so-bpmn-infra /bin/sh ) check the /app/ASDC deretory, if doesn’t exist, create it ( eg: mkdir /app/ASDC -p ) exit from the so-bpmn-infra ( eg: exit ) copy all csar files to so-bpmn-infra ( eg: kubectl.exe cp service-Siteservice-csar.csar onap/dev-so-so-bpmn-infra-54db5cd955-h7f5s:/app/ASDC/1/service-Siteservice-csar.csar )

5) Manual steps in closed loop Scenario: Following steps were undertaken for the closed loop testing. a. Give controller ip, username and password, trust store and key store file in restconf collector b. Updated DMAAP ip in cambria.hosts in DmaapConfig.json in restconf collector and run restconf collector c. Followed the steps provided in this link( to push CCVPN rules to holmes d. Followed the steps provided in this link( as reference to push CCVPN policies to policy module and updated sdnc.url, username and password in environment(/opt/app/policy/config/ As per wiki (Policy on OOM), script is used to install policies. but I observed that CCVPN policy is not added in this script. So merged CCVPN policy using POLICY-1356 JIRA ticket. but policy is pushed by using script during integration test. It is found that the changes made were overwritten and hence had to patch the DG manually. This will be tracked by the JIRA SDNC-540.

all above manual steps can be found