docs/docs_CCVPN.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0
   2    International License. http://creativecommons.org/licenses/by/4.0
   3
   4 .. _docs_ccvpn:
   5
   6 CCVPN (Cross Domain and Cross Layer VPN)
   7 ----------------------------------------
   8
   9 Update for Guilin Release
  10 ~~~~~~~~~~~~~~~~~~~~~~~~~
  11
  12 In Guilin Release, MDONS Extension feature is introduced.
  13
  14
  15 Guilin Scope and Impacted modules
  16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  17 MDONS Extension implementation for the Frankfurt release will incorporate the following:
  18
  19 - Support Asynchronous OpenRoadM OTN service activation notification handling
  20 - Add OOF support for inter domain link/path selection
  21 - Support Closed Loop sub-use case
  22 Impacted ONAP modules include: OOF, SDN-C, SO and Holmes
  23
  24 Wiki link reference: https://wiki.onap.org/display/DW/MDONS+Extension+in+R7
  25
  26 Functional/Integration Test Cases
  27 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  28 For integration test case and description, refer to this following wiki-page:
  29 https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension
  30
  31 Installation Procedure
  32 ~~~~~~~~~~~~~~~~~~~~~~
  33 The integration test environment is established to have ONAP instance with Guilin
  34 release interfacing to 3rd party transport domain controllers. One controller
  35 instance manages OpenROADM OTN topology and the other 2 instances manage TAPI
  36 OTN topology. L0 infrastructure and WDM services are pre-provisioned to support
  37 L1 topology discovery and OTN service orchestration from ONAP.
  38
  39 Testing Procedure
  40 ~~~~~~~~~~~~~~~~~
  41 https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension
  42
  43
  44 Update for Frankfurt release
  45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  46 In Frankfurt, we introduced two extensions in CCVPN use case. One is E-LINE service over OTN NNI handover, another is the
  47 multi domain optical service which aims to provide end to end layer 1 service.
  48
  49 E-LINE over OTN NNI
  50 ~~~~~~~~~~~~~~~~~~~
  51 Description
  52 ~~~~~~~~~~~
  53 It is considered a typical scenario for operators to use OTN to interconnect its multiple transport network domains. Hence
  54 the capabilities of orchestrating end-to-end E-LINE services across the domains over OTN is important for ONAP.  When operating
  55 with multiple domains with multi vendor solutions, it is also important to define and use standard and open
  56 interfaces, such as the IETF ACTN-based transport YANG models(https://tools.ietf.org/html/rfc8345), as the southbound interface
  57 of ONAP, in order to ensure interoperability. The SOTN NNI use-case aims to automate the design, service provision by independent
  58 operational entities within a service provider network by delivering E-Line over OTN orchestration capabilities into ONAP. SOTN NNI
  59 extends upon the CCVPN use-case by incorporating support for L1/L2 network management capabilities leveraging open standards & common
  60 data models.
  61
  62 Frankfurt Scope and Impacted modules
  63 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  64 The Frankfurt demonstration includes L1(OTN) and L2(ETH) Topology discovery from multiple domains controllers with in an operator
  65 and provide VPN service provision in OTN and ETH network.
  66
  67 The ONAP components involved in this use case are: SDC, A&AI, UUI, SO, SDNC, OOF, MSB.
  68
  69 Functional Test Cases
  70 ~~~~~~~~~~~~~~~~~~~~~
  71 Usecase specific developments have been realized in SO, OOF, AAI, SDNC and UUI ONAP components..
  72
  73 All test case covered by this use case:
  74 https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases
  75
  76 Testing Procedure
  77 ~~~~~~~~~~~~~~~~~
  78 Design time
  79 SOTNVPNInfraService service design in SDC and distribute to AAI and SO.
  80
  81 Run Time:
  82 All operation will be triggered by UUI, including service creation and termination, link management and topology network display.
  83
  84 More details can be found here:
  85 https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases
  86
  87 Test status can be found here:
  88 https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status
  89
  90 MDONS (Multi-Domain Optical Network Services)
  91 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  92 Overall Description
  93 ~~~~~~~~~~~~~~~~~~~
  94 The MDONS use-case aims to automate the design, activation & operations resulting from an optical transport (L0/L1) service request exchange between service providers and/or independent operational entities within a service provider network by delivering E2E optical orchestration capabilities into ONAP. MDONS extends upon the CCVPN use-case by incorporating support for L0/L1 network management capabilities leveraging open standards & common data models defined by OpenROADM, Transport-API & MEF.
  95
  96 Frankfurt Scope and Impacted modules
  97 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  98 MDONS implementation for the Frankfurt release will incorporate the following:
  99 - Design & modelling of optical services based on MEF L1 subscriber & operator properties
 100 - E2E optical service workflow definitions for service instantiation & deletion
 101 - UI portal with L1 service instantiation templates
 102 - Optical Transport domain management (topology, resource onboarding) through standard models / APIs - OpenROADM, T-API
 103 Impacted ONAP modules include: A&AI, SDC, SDN-C, SO, UUI
 104
 105 OpenROADM reference: https://github.com/OpenROADM/OpenROADM_MSA_Public
 106 ONF Transport-API (TAPI): https://github.com/OpenNetworkingFoundation/TAPI
 107 MEF: https://wiki.mef.net/display/CESG/MEF+63+-+Subscriber+Layer+1+Service+Attributes
 108
 109 Functional/Integration Test Cases
 110 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 111 For integration test case and description, refer to this following wiki-page:
 112 https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case
 113
 114 Installation Procedure
 115 ~~~~~~~~~~~~~~~~~~~~~~
 116 The integration test environment is established to have ONAP instance with Frankfurt release interfacing to 3rd party transport domain controllers. One controller instance manages OpenROADM OTN topology and the other 2 instances manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned to support L1 topology discovery and OTN service orchestration from ONAP.
 117
 118 Testing Procedure
 119 ~~~~~~~~~~~~~~~~~
 120 Test environment is described in Installation Procedure section and test procedure is described in https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case.
 121
 122
 123 Update for Dublin release
 124 ~~~~~~~~~~~~~~~~~~~~~~~~~
 125
 126 1. Service model optimization
 127
 128 In Dublin release,the design of CCVPN was optimized by having support of List type of Input in SDC.
 129 During onboarding and design phase, one end to end service is created using SDC. This service is
 130 composed of these two kinds of resources:
 131 • VPN resource
 132 • Site resource
 133 You can see the details from here https://wiki.onap.org/display/DW/Details+of+Targeted+Service+Template
 134
 135 2. Closed Loop in bandwidth adjustment
 136 Simulate alarm at the edge site branch and ONAP will execute close-loop automatically and trigger bandwidth to change higher.
 137
 138 3. Site Change
 139 Site can be add or delete according to the requirements
 140
 141
 142 More information about CCVPN in Dublin release:https://wiki.onap.org/pages/viewpage.action?pageId=45296665
 143 and the test case in Dublin can be found:https://wiki.onap.org/display/DW/CCVPN+Test+Cases+for+Dublin+Release
 144 And test status:https://wiki.onap.org/display/DW/CCVPN+Test+Status
 145
 146 Note: CCVPN integration testing coversed service design, service creation and closed-loop bandwidth adjustments in Dublin release.
 147 The service termination and service change will continue to be tested in E release.
 148 During the integration testing, SDC, SO, SDC master branch are used which include the enhanced features for CCVPN use case.
 149
 150
 151 Service used for CCVPN
 152 ~~~~~~~~~~~~~~~~~~~~~~
 153
 154 - SOTNVPNInfraService, SDWANVPNInfraService and SIteService: https://wiki.onap.org/display/DW/CCVPN+Service+Design
 155 - WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ): https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design
 156
 157 Description
 158 ~~~~~~~~~~~
 159 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.
 160
 161 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.
 162
 163 The CCVPN Use Case Wiki Page can be found here: https://wiki.onap.org/display/DW/CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE.
 164
 165 The projects covered by this use case include: SDC, A&AI, UUI, SO, SDNC, OOF, Policy, DCAE(Holmes), External API, MSB
 166
 167 How to Use
 168 ~~~~~~~~~~
 169 Design time
 170 SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps can be found here: https://wiki.onap.org/display/DW/CCVPN+Service+Design
 171 WanConnectionService ( Another way to describe CCVPN in a single service form which based on ONF CIM ): https://wiki.onap.org/display/DW/CCVPN+Wan+Connection+Service+Design
 172
 173 Run Time:
 174 All opertion will be triggerd by UUI, inlcuding service creation and termination, link management and topology network display.
 175
 176
 177 More details can be fonud here: https://wiki.onap.org/display/DW/CCVPN+Test+Guide
 178
 179 Test Status and Plans
 180 ~~~~~~~~~~~~~~~~~~~~~
 181 All test case covered by this use case: https://wiki.onap.org/display/DW/CCVPN+Integration+Test+Case
 182
 183 And the test status can be found: https://wiki.onap.org/display/DW/CCVPN++-Test+Status
 184
 185 Known Issues and Resolutions
 186 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 187 1) AAI-1923. Link Management, UUI can't delete the link to external onap otn domain.
 188
 189 For the manual steps provided by A&AI team, we should follow the steps as follow
 190 the only way to delete is using the forceDeleteTool shell script in the graphadmin container.
 191 First we will need to find the vertex id, you should be able to get the id by making the following GET request.
 192
 193 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete/esr-system-info/test-esr-system-info-id-val-0?format=raw
 194
 195 .. code-block:: JSON
 196
 197   {
 198
 199     "results": [
 200       {
 201         "id": "20624",
 202         "node-type": "pserver",
 203         "url": "/aai/v13/cloud-infrastructure/pservers/pserver/pserverid14503-as988q",
 204         "properties": {}
 205       }
 206     ]
 207   }
 208
 209
 210 Same goes for the ext-aai-network:
 211
 212 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete?format=raw
 213
 214 Retrieve the id from the above output as that will be the vertex id that you want to remove.
 215
 216 Run the following command multiple times for both the esr-system-info and ext-aai-network:
 217
 218 ::
 219
 220   kubectl exec -it $(kubectl get pods -lapp=aai-graphadmin -n onap --template 'range .items.metadata.name"\n"end' | head -1) -n onap gosu aaiadmin /opt/app/aai-graphadmin/scripts/forceDeleteTool.sh -action DELETE_NODE -userId YOUR_ID_ANY_VALUE -vertexId VERTEX_ID
 221
 222 From the above, remove the YOUR_ID_ANY_VALUE and VERTEX_ID with your info.
 223
 224 2) SDC-1955. Site service Distribution
 225
 226 To overcome the Service distribution, the SO catalog has to be populated with the model information of the services and resources.
 227 a) Refering to the Csar that is generated in the SDC designed as per the detailes mentioned in the below link: https://wiki.onap.org/display/DW/CCVPN+Service+Design
 228 b) Download the Csar from SDC thus generated.
 229 c) copy the csar to SO sdc controller pod and bpmn pod
 230
 231 .. code-block:: bash
 232
 233   kubectl -n onap get pod|grep so
 234   kubectl -n onap exec -it dev-so-so-sdc-controller-c949f5fbd-qhfbl  /bin/sh
 235   mkdir null/ASDC
 236   mkdir null/ASDC/1
 237   kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar  dev-so-so-bpmn-infra-58796498cf-6pzmz:null/ASDC/1/service-Sdwanvpninfraservice-csar.csar
 238   kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar  dev-so-so-bpmn-infra-58796498cf-6pzmz:ASDC/1/service-Sdwanvpninfraservice-csar.csar
 239
 240 d) populate model information to SO db: the db script example can be seen in
 241    https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing
 242
 243 The same would also be applicable for the integration of the client to create the service and get the details.
 244 Currently the testing has been performed using the postman calls to the corresponding APIs.
 245
 246 3) SDC-1955 & SDC-1958. Site serivce parsing Error
 247
 248 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
 249 a) Make an available csar file for CCVPN use case.
 250 b) Replace uuid of available files with what existing in SDC.
 251 c) Put available csar files in UUI local path (/home/uui).
 252
 253 4) SO docker branch 1.3.5 has fixes for the issues 1SO-1248
 254
 255 After SDC distribution success, copy all csar files from so-sdc-controller:
 256
 257 - connect to so-sdc-controller ( eg: kubectl.exe exec -it -n onap dev-so-so-sdc-controller-77df99bbc9-stqdz /bin/sh )
 258 - find out all csar files ( eg: find / -name "\*.csar" ), the csar files should
 259   be in this path: /app/null/ASDC/ ( eg: /app/null/ASDC/1/service-Sotnvpninfraservice-csar.csar )
 260 - exit from the so-sdc-controller ( eg: exit )
 261 - 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 )
 262
 263 Copy csar files, which got from so-sdc-controller, to so-bpmn-infra:
 264
 265 - 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 )
 266 - check the /app/ASDC deretory, if doesn't exist, create it ( eg: mkdir /app/ASDC -p )
 267 - exit from the so-bpmn-infra ( eg: exit )
 268 - 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 )