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