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