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