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