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