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 Update for London Release
  11 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  12
  13 The London release enhances the CCVPN use-case by introducing the Cloud-Network Convergence support (REQ-1413).
  14 CCVPN London release will add transport domain support for the Intent-based cloud-network convergence.
  15
  16 London Scope and Impacted modules
  17 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  18
  19 The standardized cloud resource management APIs are still under our investigation.
  20 In London, we will only support the registration of the Cloud Orchestrator to SNDC,
  21 whose mechanism is similar to the network controller registration.
  22
  23 The impacted ONAP modules are CCSDK and SDN-C.
  24
  25 Installation Procedure
  26 ~~~~~~~~~~~~~~~~~~~~~~
  27
  28 For London's new features, the integration test environment is similar to that of
  29 the Kohn release: an ONAP instance with London release interfacing with 3rd party
  30 cloud orchestrators should be established.
  31
  32 Functional/Integration Test Cases
  33 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  34
  35 The testing procedure is described in the following few test cases:
  36 - Register a 3rd party cloud orchestrator to SDNC through ESR APIs
  37 - Create and delete a single CLL instance that accesses a single cloud, and monitor if the closed-loop call flow is getting triggered.
  38 - Modify the bandwidth of a connection link of an existing CLL instance, and monitor if the closed-loop call flow is getting triggered.
  39
  40 Update for kohn Release
  41 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  42
  43 The kohn release enhances the CCVPN use-case by introducing the following three features (REQ-1268):
  44 1. E-LINE (P2P connection) support for the Cloud Leased Line (CLL) service delivery
  45 2. Enhancing the Closed-Loop Automation of CCVPN services by using DCAE SDK dmaap-client lib in slice analysis MS
  46 3. Enhancing TN NSSMF NBI to align with the latest IETF specification (SO changes)
  47
  48 Kohn Scope and Impacted modules
  49 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  50
  51 The Kohn release is an enhancement release. E-LINE service model (P2P connection) is added to the Cloud Leased Line (CLL) service.
  52 Also, slice analysis MS is enhanced to use DCAE SDK dmaap-client lib.
  53 And lastly, TN NSSMF northbound is aligned with the latest IETF transport slice definition model (SO changes).
  54
  55 The impacted ONAP modules are: CCSDK, SDN-C, DCAE, and SO.
  56
  57 Installation Procedure
  58 ~~~~~~~~~~~~~~~~~~~~~~
  59
  60 For Kohn new features, the integration test environment is similar to that of
  61 the Jakarta release: an ONAP instance with Kohn release interfacing with 3rd party
  62 transport domain controllers should be established.
  63
  64 Functional/Integration Test Cases
  65 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  66
  67 The testing procedure is described in the following few test cases:
  68 - Create and delete single CLL instance which accesses single cloud, and monitor if the closed-loop call flow is getting triggered.
  69 - Modify the bandwidth of a connection link of an existing CLL instance, and monitor if the closed-loop call flow is getting triggered.
  70
  71
  72 Update for Jakarta Release
  73 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  74
  75 The Jakarta release enhances the CCVPN use-case by introducing the following three features (REG-1076):
  76 1. Support for IBN service discovery by registering Cloud Leased Line (CLL) and Transport Slicing services to MSB
  77 2. Support for 1+1 protection of Cloud Leased Line (CLL)
  78 3. Support for closed-loop and user-triggered intent update
  79
  80 Jakarta Scope and Impacted modules
  81 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  82
  83 The "CCVPN closed-loop" feature and the "user-triggered intent update" feature require both a front-end and a back-end system.
  84 The front-end would be different for IBN and CCVPN, but the two features can share a common back-end.
  85 As a first step, current bandwidth usage of a CLL should be collected from the physical network. Then VES collector API
  86 should be called to send this information to DCAE. DCAE would then publish a new DMaaP topic to be consumed by DCAE slice
  87 analysis micro-service. This module will then send this notification to Policy.
  88
  89 In Jakarta, the goal of both user-triggered intent update and CCVPN closed-loop is to ensure the max-bandwidth of the CLL service
  90 can satisfy user's intent throughout the intent life cycle. Thus, the modify-CLL operation triggered by DCAE and Policy is
  91 common to IBN and CCVPN. So a common back-end mechanism is implemented to support both use-cases.
  92
  93 The impacted ONAP modules are: CCSDK, SDN-C, A&AI, DCAE, POLICY, and SO.
  94
  95 Installation Procedure
  96 ~~~~~~~~~~~~~~~~~~~~~~
  97
  98 For Jakarta new features, the integration test environment is similar to that of
  99 the Istanbul release: an ONAP instance with Istanbul release interfacing with 3rd party
 100 transport domain controllers should be established.
 101
 102 Functional/Integration Test Cases
 103 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 104
 105 The testing procedure is described in the following few test cases:
 106 - Create and delete single CLL instance which accesses single cloud, and monitor if the closed-loop call flow is getting triggered.
 107 - Create and delete single CLL instance which access multiple clouds, and monitor if the closed-loop call flow is getting triggered.
 108 - Create and delete multiple CLL instances which access single cloud, and monitor if the closed-loop call flow is getting triggered.
 109 - Create and delete multiple CLL instances which access multiple clouds, and monitor if the closed-loop call flow is getting triggered.
 110 - Create a CLL instance which have connection links with different bandwidth, and monitor if the closed-loop call flow is getting triggered.
 111 - Modify the bandwidth of a connection link of an existing CLL instance, and monitor if the closed-loop call flow is getting triggered.
 112 - Modify an existing CLL instance by add a new connection link, and monitor if the closed-loop call flow is getting triggered.
 113
 114
 115 Update for Istanbul Release
 116 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 117
 118 The Istanbul release introduces a new functionality for the CCVPN use-case:
 119 Cloud Lease Line (CLL) service support. The following three main operations were
 120 added in Istanbul release (REQ-719):
 121
 122 1. The support for creating an E-Tree service, which has one ROOT (Cloud POP) and may have
 123    one or more LEAFs (i.e. ONUs) as its branches.
 124 2. The support for modifying the maximum bandwidth supported by a given E-Tree.
 125 3. The support for deleting an E-Tree service.
 126
 127 Istanbul Scope and Impacted modules
 128 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 129
 130 For operation #1 mentioned above, the user should be able to "create" an E-Tree service.
 131 The modification operation is able to support the following scenarios:
 132
 133 a. An E-Tree can have one or more branches (LEAFs) located in one or multiple (different)
 134    domains.
 135 b. When multiple LEAFs are physically located in a single OLT node, those LEAFs
 136    should re-use or share the same OTN tunnels, therefore the path computation
 137    mechanism should only be called once.
 138
 139 By operation #2 mentioned above, a user can change/modify the maximum bandwidth supported
 140 by a given E-Tree.
 141
 142 And by operation #3 mentioned above, a user can delete a given E-Tree.
 143
 144 The impacted ONAP modules are: SO, SDN-C, and A&AI.
 145
 146 For A&AI, additional edge-rules were introduced between two connectivity nodes as well as
 147 between a connectivity and a uni node.
 148
 149 In SDN-C, additional Directed Graphs (DGs) were implemented to support the above-mentioned
 150 features. These new DGs are placed under the generic-resource-api folder in SDNC.
 151
 152 Installation Procedure
 153 ~~~~~~~~~~~~~~~~~~~~~~
 154
 155 For Istanbul new features, the integration test environment is similar to that of
 156 the Honolulu release: an ONAP instance with Istanbul release interfacing with 3rd party
 157 transport domain controllers should be established.
 158
 159 For E-Tree support, the installation procedure is similar to that of the E2E
 160 Network Slicing use case. In other words, we need to bring up the required modules
 161 including SO, ADNS, A&AI, and UUI. We also need to configure these modules along
 162 with the mandatory common modules such as DMaaP.
 163
 164 Functional/Integration Test Cases
 165 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 166
 167 The testing procedure is described in the following few test cases:
 168
 169 - create an E-Tree with one ROOT and one or multiple LEAF(s) in a multi-domain topology
 170 - modify the maximum bw of a given E-Tree or add a new connection link to a given E-Tree
 171 - delete a given E-Tree
 172
 173 To run such test cases, the user must first add (register) the domain controllers as the ESR
 174 3rd party controllers. As a result of this registration, a round of topology discovery gets
 175 triggered. After that, network-routes or UNI Endpoints have to be created in A&AI. This step
 176 is similar to that of Guilin release, and is described in the following link:
 177 https://wiki.onap.org/display/DW/Transport+Slicing+Configuration+and+Operation+Guidance
 178
 179 Then an E-Tree creation, modification and deletion can be triggered from SO APIs.
 180
 181
 182
 183 Update for Honolulu Release
 184 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
 185
 186 The Honolulu release continued to support and extend the Transport Slicing functionality
 187 developed in Guilin release. Two main features were aded in Honolulu release (REQ-456):
 188
 189 1. The support for reuse and modification of an existing TN NSSI has been developed.
 190 2. In addition, the Honolulu release also continuted to support and extend the CCVPN
 191    use-case and in particular, the support for inter-domain connections of three or
 192    more network domains has been introduced in Honolulu release. (CCVPN in previous
 193    releases were only be able to connect two domains).
 194
 195 Honolulu Scope and Impacted modules
 196 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 197
 198 For feature #1 mentioned above, the user should be able to "modify" a Transport Slice.
 199 The modification operation is able to support the following three scenarios:
 200
 201 a. A user may "Add" one or more new service(s)/connections link(s) to a given slice
 202    (TN NSSI) that is already created.
 203 b. A user may need to change or modify the maximum bandwidth attribute (i.e. the SLA
 204    agreement) using which a given slice is created.
 205 c. Both of the above operations.
 206
 207 For feature #2 mentioned above, now in H release, we can have and support an artibrary
 208 number of domains inter-connected to each other and we can support a cross-layer
 209 cross-domain VPN connectivity and transport slicing for these kinds of scenarios as well.
 210
 211 Impacted ONAP modules include: SO, SDN-C, CCSDK, A&AI.
 212
 213 In CCSDk, a path computation engine (PCE) mechanism is introduced to support a
 214 graph-based path computation in a multi-domain network topologies. This PCE system is
 215 implemented as a SLI plugin to be called and used by Directed Graphs (DGs).
 216
 217 For A&AI, additional attributes were introduced to the connectivity node and vpn-binding node.
 218
 219 In SDN-C, additional Directed Graphs (DGs) were implemented to support the above-mentioned
 220 two features.
 221
 222 Installation Procedure
 223 ~~~~~~~~~~~~~~~~~~~~~~
 224
 225 For Honolulu new features, the integration test environment is similar to that of the Guilin
 226 release: an ONAP instance with Honolulu release interfacing to 3rd party transport domain
 227 controllers should be established.
 228
 229 For Transport Slicing, the installation procedure is similar to that of the E2E
 230 Network Slicing use case. In other words, we need to bring up the required modules
 231 including SDC, SO, A&AI, UUI and OOF. We also need to configure these modules along
 232 with the mandatory common modules such as DMaaP.
 233
 234 Functional/Integration Test Cases
 235 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 236
 237 The testing procedure is described in the following few test cases:
 238
 239 - service/template design: Successful design of TN NSST and Slice Profile
 240 - modify max-bandwidth of existing TN NSSI: Modify the maximum bandwidth of an existing TN NSSI
 241 - modify connection links existing TN NSSI: Add new connection links to existing TN NSSI
 242 - 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
 243 - 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)
 244
 245
 246
 247 Update for Guilin Release
 248 ~~~~~~~~~~~~~~~~~~~~~~~~~
 249
 250 In Guilin Release, **MDONS** Extension feature is introduced.
 251
 252 In addition to the MDONS extension, CCVPN has also developed an
 253 IETF/ACTN-based Transport Slicing solution (REQ-347). This development
 254 enabled ONAP to offer the TN NSSMF functionality, which was used by
 255 the E2E Network Slicing use case (REQ-342).  The solution was built
 256 upon the existing IETF/ACTN E-LINE over OTN NNI feature developed in Frankfurt release.
 257
 258 Guilin Scope and Impacted modules
 259 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 260 MDONS Extension implementation for the Frankfurt release will incorporate the following:
 261
 262 - Support Asynchronous OpenRoadM OTN service activation notification handling
 263 - Add OOF support for inter domain link/path selection
 264 - Support Closed Loop sub-use case
 265
 266 Impacted ONAP modules include: OOF, SDN-C, SO and Holmes.
 267
 268 `Wiki link reference <https://wiki.onap.org/display/DW/MDONS+Extension+in+R7>`_
 269
 270 Transport Slicing in Guilin release has implemented the following TN NSSMF functionality:
 271
 272 - Allocate TN NSSI
 273 - Deallocate TN NSSI
 274 - Activate TN NSSI
 275 - Deactivate TN NSSI
 276
 277 The Tranport Slicing implementation has made code changes in the following modules:
 278
 279 - AAI (Schema changes only)
 280 - UUI
 281 - SO
 282 - OOF
 283 - SDN-C
 284 - CCSDK
 285 - Modelling
 286
 287 Functional/Integration Test Cases
 288 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 289
 290 For integration test case and description of MDONS extension, refer to this
 291 `following wiki-page <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_.
 292
 293 For integration test case and description of Transport Slicing:
 294
 295 - `Guilin Test plan <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_
 296 - `Guilin E2E Network Slicing <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R7+Guilin>`_
 297
 298 Installation Procedure
 299 ~~~~~~~~~~~~~~~~~~~~~~
 300
 301 For MDONS extension, the integration test environment is established to have ONAP instance with Guilin
 302 release interfacing to 3rd party transport domain controllers. One controller
 303 instance manages OpenROADM OTN topology and the other 2 instances manage TAPI
 304 OTN topology. L0 infrastructure and WDM services are pre-provisioned to support
 305 L1 topology discovery and OTN service orchestration from ONAP.
 306
 307 For Transport Slicing, the installation procedure is similar to that of the E2E
 308 Network Slicing use case. In other words, we need to bring up the required modules
 309 including SDC, SO, A&AI, UUI and OOF. We also need to configure these modules along
 310 with the mandatory common modules such as DMaaP.
 311
 312 Testing Procedures
 313 ~~~~~~~~~~~~~~~~~~
 314
 315 The testing procedure is described in:
 316
 317 - `Testing procedure for MDONS extension <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_
 318 - `Testing procedure for Transport Slicing <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_
 319
 320 Update for Frankfurt release
 321 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 322
 323 In Frankfurt, we introduced two extensions in CCVPN use case. One is E-LINE service over OTN NNI handover, another is the
 324 multi domain optical service which aims to provide end to end layer 1 service.
 325
 326 E-LINE over OTN NNI
 327 ~~~~~~~~~~~~~~~~~~~
 328
 329 Description
 330 ~~~~~~~~~~~
 331
 332 It is considered a typical scenario for operators to use OTN to interconnect its multiple transport network domains. Hence
 333 the capabilities of orchestrating end-to-end E-LINE services across the domains over OTN is important for ONAP.  When operating
 334 with multiple domains with multi vendor solutions, it is also important to define and use standard and open
 335 interfaces, such as the IETF ACTN-based transport `YANG models <https://tools.ietf.org/html/rfc8345>`_, as the southbound interface
 336 of ONAP, in order to ensure interoperability. The SOTN NNI use-case aims to automate the design, service provision by independent
 337 operational entities within a service provider network by delivering E-Line over OTN orchestration capabilities into ONAP. SOTN NNI
 338 extends upon the CCVPN use-case by incorporating support for L1/L2 network management capabilities leveraging open standards & common
 339 data models.
 340
 341 Frankfurt Scope and Impacted modules
 342 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 343
 344 The Frankfurt demonstration includes L1(OTN) and L2(ETH) Topology discovery from multiple domains controllers with in an operator
 345 and provide VPN service provision in OTN and ETH network.
 346
 347 The ONAP components involved in this use case are: SDC, A&AI, UUI, SO, SDNC, OOF, MSB.
 348
 349 Functional Test Cases
 350 ~~~~~~~~~~~~~~~~~~~~~
 351
 352 Usecase specific developments have been realized in SO, OOF, AAI, SDNC and UUI ONAP components..
 353
 354 Testing Procedure
 355 ~~~~~~~~~~~~~~~~~
 356 Design time
 357 SOTNVPNInfraService service design in SDC and distribute to AAI and SO.
 358
 359 Run Time:
 360 All operation will be triggered by UUI, including service creation and termination,
 361 link management and topology network display:
 362
 363 - `E-LINE over OTN Inter Domain Test Cases <https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases>`_
 364 - `Testing status <https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status>`_
 365
 366 MDONS (Multi-Domain Optical Network Services)
 367 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 368
 369 Overall Description
 370 ~~~~~~~~~~~~~~~~~~~
 371
 372 The MDONS use-case aims to automate the design, activation & operations resulting
 373 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.
 374
 375 Frankfurt Scope and Impacted modules
 376 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 377
 378 MDONS implementation for the Frankfurt release will incorporate the following:
 379 - Design & modelling of optical services based on MEF L1 subscriber & operator properties
 380 - E2E optical service workflow definitions for service instantiation & deletion
 381 - UI portal with L1 service instantiation templates
 382 - Optical Transport domain management (topology, resource onboarding) through standard models / APIs - OpenROADM, T-API
 383 Impacted ONAP modules include: A&AI, SDC, SDN-C, SO, UUI
 384
 385 References:
 386
 387 - `OpenROADM reference <https://github.com/OpenROADM/OpenROADM_MSA_Public>`_
 388 - `ONF Transport-API (TAPI) <https://github.com/OpenNetworkingFoundation/TAPI>`_
 389 - `MEF <https://wiki.mef.net/display/CESG/MEF+63+-+Subscriber+Layer+1+Service+Attributes>`_
 390
 391 Functional/Integration Test Cases
 392 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 393
 394 For integration test case and description, refer to this following
 395 `wiki-page <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_.
 396
 397 Installation Procedure
 398 ~~~~~~~~~~~~~~~~~~~~~~
 399
 400 The integration test environment is established to have ONAP instance with
 401 Frankfurt release interfacing to 3rd party transport domain controllers.
 402 One controller instance manages OpenROADM OTN topology and the other 2 instances
 403 manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned
 404 to support L1 topology discovery and OTN service orchestration from ONAP.
 405
 406 Testing Procedure
 407 ~~~~~~~~~~~~~~~~~
 408
 409 Test environment is described in
 410 `Installation and Test Procedure <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_.
 411
 412 Update for Dublin release
 413 ~~~~~~~~~~~~~~~~~~~~~~~~~
 414
 415 1. Service model optimization
 416
 417 In Dublin release,the design of CCVPN was optimized by having support of List type of Input in SDC.
 418 During onboarding and design phase, one end to end service is created using SDC.
 419 This service is composed of these two kinds of resources:
 420
 421 - VPN resource
 422 - Site resource
 423
 424 See the `Details of Targeted Service Template wiki page <https://wiki.onap.org/display/DW/Details+of+Targeted+Service+Template>`_
 425 for details.
 426
 427 2. Closed Loop in bandwidth adjustment
 428 Simulate alarm at the edge site branch and ONAP will execute close-loop automatically and trigger bandwidth to change higher.
 429
 430 3. Site Change
 431 Site can be add or delete according to the requirements
 432
 433 More information about:
 434
 435 - `CCVPN in Dublin release <https://wiki.onap.org/pages/viewpage.action?pageId=45296665>`_
 436 - `Dublin test cases <https://wiki.onap.org/display/DW/CCVPN+Test+Cases+for+Dublin+Release>`_
 437 - `CCVPN Test Status wiki page <https://wiki.onap.org/display/DW/CCVPN+Test+Status>`_
 438
 439 .. note::
 440     CCVPN integration testing coversed service design, service creation and
 441     closed-loop bandwidth adjustments in Dublin release.
 442
 443     The service termination and service change will continue to be tested in E release.
 444     During the integration testing, SDC, SO, SDC master branch are used which
 445     includes the enhanced features for CCVPN use case.
 446
 447 Service used for CCVPN
 448 ~~~~~~~~~~~~~~~~~~~~~~
 449
 450 - `SOTNVPNInfraService, SDWANVPNInfraService and SIteService <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_
 451 - `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>`_
 452
 453 Description
 454 ~~~~~~~~~~~
 455
 456 Cross-domain, cross-layer VPN (CCVPN) is one of the use cases of the ONAP
 457 Casablanca release. This release demonstrates cross-operator ONAP orchestration
 458 and interoperability with third party SDN controllers and enables cross-domain,
 459 cross-layer and cross-operator service creation and assurance.
 460
 461 The demonstration includes two ONAP instances, one deployed by Vodafone and one
 462 by China Mobile, both of which orchestrate the respective operator underlay OTN
 463 networks and overlay SD-WAN networks and peer to each other for cross-operator
 464 VPN service delivery.
 465
 466 `CCVPN Use Case Wiki Page <https://wiki.onap.org/display/DW/CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE>`_
 467
 468 The projects covered by this use case include: SDC, A&AI, UUI, SO, SDNC, OOF, Policy, DCAE(Holmes), External API, MSB
 469
 470 How to Use
 471 ~~~~~~~~~~
 472
 473 Design time:
 474
 475 - `SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_
 476 - `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>`_
 477
 478 Run Time:
 479
 480 - All operations will be triggered by UUI, including service creation and termination,
 481   link management and topology network display.
 482
 483
 484 See the `CCVPN Test Guide wiki page <https://wiki.onap.org/display/DW/CCVPN+Test+Guide>`_
 485 for details.
 486
 487 Test Status and Plans
 488 ~~~~~~~~~~~~~~~~~~~~~
 489
 490 - `All test case covered by this use case <https://wiki.onap.org/display/DW/CCVPN+Integration+Test+Case>`_
 491 - `Test status <https://wiki.onap.org/display/DW/CCVPN++-Test+Status>`_
 492
 493 Known Issues and Resolutions
 494 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 495
 496 1) AAI-1923. Link Management, UUI can't delete the link to external onap otn domain.
 497
 498 For the manual steps provided by A&AI team, we should follow the steps as follow
 499 the only way to delete is using the forceDeleteTool shell script in the graphadmin container.
 500 First we will need to find the vertex id, you should be able to get the id by making the following GET request.
 501
 502 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete/esr-system-info/test-esr-system-info-id-val-0?format=raw
 503
 504 .. code-block:: JSON
 505
 506   {
 507
 508     "results": [
 509       {
 510         "id": "20624",
 511         "node-type": "pserver",
 512         "url": "/aai/v13/cloud-infrastructure/pservers/pserver/pserverid14503-as988q",
 513         "properties": {}
 514       }
 515     ]
 516   }
 517
 518
 519 Same goes for the ext-aai-network:
 520
 521 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete?format=raw
 522
 523 Retrieve the id from the above output as that will be the vertex id that you want to remove.
 524
 525 Run the following command multiple times for both the esr-system-info and ext-aai-network:
 526
 527 ::
 528
 529   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
 530
 531 From the above, remove the YOUR_ID_ANY_VALUE and VERTEX_ID with your info.
 532
 533 2) SDC-1955. Site service Distribution
 534
 535 To overcome the Service distribution, the SO catalog has to be populated with the model information of the services and resources.
 536 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
 537 b) Download the Csar from SDC thus generated.
 538 c) copy the csar to SO sdc controller pod and bpmn pod
 539
 540 .. code-block:: bash
 541
 542   kubectl -n onap get pod|grep so
 543   kubectl -n onap exec -it dev-so-so-sdc-controller-c949f5fbd-qhfbl  /bin/sh
 544   mkdir null/ASDC
 545   mkdir null/ASDC/1
 546   kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar  dev-so-so-bpmn-infra-58796498cf-6pzmz:null/ASDC/1/service-Sdwanvpninfraservice-csar.csar
 547   kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar  dev-so-so-bpmn-infra-58796498cf-6pzmz:ASDC/1/service-Sdwanvpninfraservice-csar.csar
 548
 549 d) populate model information to SO db: the db script example can be seen in
 550    https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing
 551
 552 The same would also be applicable for the integration of the client to create the service and get the details.
 553 Currently the testing has been performed using the postman calls to the corresponding APIs.
 554
 555 3) SDC-1955 & SDC-1958. Site service parsing Error
 556
 557 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
 558 a) Make an available csar file for CCVPN use case.
 559 b) Replace uuid of available files with what existing in SDC.
 560 c) Put available csar files in UUI local path (/home/uui).
 561
 562 4) SO docker branch 1.3.5 has fixes for the issues 1SO-1248
 563
 564 After SDC distribution success, copy all csar files from so-sdc-controller:
 565
 566 - connect to so-sdc-controller ( eg: kubectl.exe exec -it -n onap dev-so-so-sdc-controller-77df99bbc9-stqdz /bin/sh )
 567 - find out all csar files ( eg: find / -name "\*.csar" ), the csar files should
 568   be in this path: /app/null/ASDC/ ( eg: /app/null/ASDC/1/service-Sotnvpninfraservice-csar.csar )
 569 - exit from the so-sdc-controller ( eg: exit )
 570 - 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 )
 571
 572 Copy csar files, which got from so-sdc-controller, to so-bpmn-infra:
 573
 574 - 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 )
 575 - check the /app/ASDC directory, if doesn't exist, create it ( eg: mkdir /app/ASDC -p )
 576 - exit from the so-bpmn-infra ( eg: exit )
 577 - 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 )