1 .. This work is licensed under a Creative Commons Attribution 4.0
2 International License. http://creativecommons.org/licenses/by/4.0
8 CCVPN (Cross Domain and Cross Layer VPN)
9 ----------------------------------------
10 Update for Jakarta Release
11 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
13 The Jakarta release enhances the CCVPN use-case by introducing the following three features (REG-1076):
14 1. Support for IBN service discovery by registering Cloud Leased Line (CLL) and Transport Slicing services to MSB
15 2. Support for 1+1 protection of Cloud Leased Line (CLL)
16 3. Support for closed-loop and user-triggered intent update
18 Jakarta Scope and Impacted modules
19 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
21 The "CCVPN closed-loop" feature and the "user-triggered intent update" feature require both a front-end and a back-end system.
22 The front-end would be different for IBN and CCVPN, but the two features can share a common back-end.
23 As a first step, current bandwidth usage of a CLL should be collected from the physical network. Then VES collector API
24 should be called to send this information to DCAE. DCAE would then publish a new DMaaP topic to be consumed by DCAE slice
25 analysis micro-service. This module will then send this notification to Policy.
27 In Jakarta, the goal of both user-triggered intent update and CCVPN closed-loop is to ensure the max-bandwidth of the CLL service
28 can satisfy user's intent throughout the intent life cycle. Thus, the modify-CLL operation triggered by DCAE and Policy is
29 common to IBN and CCVPN. So a common back-end mechanism is implemented to support both use-cases.
31 The impacted ONAP modules are: CCSDK, SDN-C, A&AI, DCAE, POLICY, and SO.
33 Installation Procedure
34 ~~~~~~~~~~~~~~~~~~~~~~
36 For Jakarta new features, the integration test environment is similar to that of
37 the Istanbul release: an ONAP instance with Istanbul release interfacing with 3rd party
38 transport domain controllers should be established.
40 Functional/Integration Test Cases
41 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
43 The testing procedure is described in the following few test cases:
44 - Create and delete single CLL instance which accesses single cloud, and monitor if the closed-loop call flow is getting triggered.
45 - Create and delete single CLL instance which access multiple clouds, and monitor if the closed-loop call flow is getting triggered.
46 - Create and delete multiple CLL instances which access single cloud, and monitor if the closed-loop call flow is getting triggered.
47 - Create and delete multiple CLL instances which access multiple clouds, and monitor if the closed-loop call flow is getting triggered.
48 - Create a CLL instance which have connection links with different bandwidth, and monitor if the closed-loop call flow is getting triggered.
49 - Modify the bandwidth of a connection link of an existing CLL instance, and monitor if the closed-loop call flow is getting triggered.
50 - Modify an existing CLL instance by add a new connection link, and monitor if the closed-loop call flow is getting triggered.
53 Update for Istanbul Release
54 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
56 The Istanbul release introduces a new functionality for the CCVPN use-case:
57 Cloud Lease Line (CLL) service support. The following three main operations were
58 added in Istanbul release (REQ-719):
60 1. The support for creating an E-Tree service, which has one ROOT (Cloud POP) and may have
61 one or more LEAFs (i.e. ONUs) as its branches.
62 2. The support for modifying the maximum bandwidth supported by a given E-Tree.
63 3. The support for deleting an E-Tree service.
65 Istanbul Scope and Impacted modules
66 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
68 For operation #1 mentioned above, the user should be able to "create" an E-Tree service.
69 The modification operation is able to support the following scenarios:
71 a. An E-Tree can have one or more branches (LEAFs) located in one or multiple (different)
73 b. When multiple LEAFs are physically located in a single OLT node, those LEAFs
74 should re-use or share the same OTN tunnels, therefore the path computation
75 mechanism should only be called once.
77 By operation #2 mentioned above, a user can change/modify the maximum bandwidth supported
80 And by operation #3 mentioned above, a user can delete a given E-Tree.
82 The impacted ONAP modules are: SO, SDN-C, and A&AI.
84 For A&AI, additional edge-rules were introduced between two connectivity nodes as well as
85 between a connectivity and a uni node.
87 In SDN-C, additional Directed Graphs (DGs) were implemented to support the above-mentioned
88 features. These new DGs are placed under the generic-resource-api folder in SDNC.
90 Installation Procedure
91 ~~~~~~~~~~~~~~~~~~~~~~
93 For Istanbul new features, the integration test environment is similar to that of
94 the Honolulu release: an ONAP instance with Istanbul release interfacing with 3rd party
95 transport domain controllers should be established.
97 For E-Tree support, the installation procedure is similar to that of the E2E
98 Network Slicing use case. In other words, we need to bring up the required modules
99 including SO, ADNS, A&AI, and UUI. We also need to configure these modules along
100 with the mandatory common modules such as DMaaP.
102 Functional/Integration Test Cases
103 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
105 The testing procedure is described in the following few test cases:
107 - create an E-Tree with one ROOT and one or multiple LEAF(s) in a multi-domain topology
108 - modify the maximum bw of a given E-Tree or add a new connection link to a given E-Tree
109 - delete a given E-Tree
111 To run such test cases, the user must first add (register) the domain controllers as the ESR
112 3rd party controllers. As a result of this registration, a round of topology discovery gets
113 triggered. After that, network-routes or UNI Endpoints have to be created in A&AI. This step
114 is similar to that of Guilin release, and is described in the following link:
115 https://wiki.onap.org/display/DW/Transport+Slicing+Configuration+and+Operation+Guidance
117 Then an E-Tree creation, modification and deletion can be triggered from SO APIs.
121 Update for Honolulu Release
122 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
124 The Honolulu release continued to support and extend the Transport Slicing functionality
125 developed in Guilin release. Two main features were aded in Honolulu release (REQ-456):
127 1. The support for reuse and modification of an existing TN NSSI has been developed.
128 2. In addition, the Honolulu release also continuted to support and extend the CCVPN
129 use-case and in particular, the support for inter-domain connections of three or
130 more network domains has been introduced in Honolulu release. (CCVPN in previous
131 releases were only be able to connect two domains).
133 Honolulu Scope and Impacted modules
134 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
136 For feature #1 mentioned above, the user should be able to "modify" a Transport Slice.
137 The modification operation is able to support the following three scenarios:
139 a. A user may "Add" one or more new service(s)/connections link(s) to a given slice
140 (TN NSSI) that is already created.
141 b. A user may need to change or modify the maximum bandwidth attribute (i.e. the SLA
142 agreement) using which a given slice is created.
143 c. Both of the above operations.
145 For feature #2 mentioned above, now in H release, we can have and support an artibrary
146 number of domains inter-connected to each other and we can support a cross-layer
147 cross-domain VPN connectivity and transport slicing for these kinds of scenarios as well.
149 Impacted ONAP modules include: SO, SDN-C, CCSDK, A&AI.
151 In CCSDk, a path computation engine (PCE) mechanism is introduced to support a
152 graph-based path computation in a multi-domain network topologies. This PCE system is
153 implemented as a SLI plugin to be called and used by Directed Graphs (DGs).
155 For A&AI, additional attributes were introduced to the connectivity node and vpn-binding node.
157 In SDN-C, additional Directed Graphs (DGs) were implemented to support the above-mentioned
160 Installation Procedure
161 ~~~~~~~~~~~~~~~~~~~~~~
163 For Honolulu new features, the integration test environment is similar to that of the Guilin
164 release: an ONAP instance with Honolulu release interfacing to 3rd party transport domain
165 controllers should be established.
167 For Transport Slicing, the installation procedure is similar to that of the E2E
168 Network Slicing use case. In other words, we need to bring up the required modules
169 including SDC, SO, A&AI, UUI and OOF. We also need to configure these modules along
170 with the mandatory common modules such as DMaaP.
172 Functional/Integration Test Cases
173 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
175 The testing procedure is described in the following few test cases:
177 - service/template design: Successful design of TN NSST and Slice Profile
178 - modify max-bandwidth of existing TN NSSI: Modify the maximum bandwidth of an existing TN NSSI
179 - modify connection links existing TN NSSI: Add new connection links to existing TN NSSI
180 - 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
181 - 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)
185 Update for Guilin Release
186 ~~~~~~~~~~~~~~~~~~~~~~~~~
188 In Guilin Release, **MDONS** Extension feature is introduced.
190 In addition to the MDONS extension, CCVPN has also developed an
191 IETF/ACTN-based Transport Slicing solution (REQ-347). This development
192 enabled ONAP to offer the TN NSSMF functionality, which was used by
193 the E2E Network Slicing use case (REQ-342). The solution was built
194 upon the existing IETF/ACTN E-LINE over OTN NNI feature developed in Frankfurt release.
196 Guilin Scope and Impacted modules
197 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
198 MDONS Extension implementation for the Frankfurt release will incorporate the following:
200 - Support Asynchronous OpenRoadM OTN service activation notification handling
201 - Add OOF support for inter domain link/path selection
202 - Support Closed Loop sub-use case
204 Impacted ONAP modules include: OOF, SDN-C, SO and Holmes.
206 `Wiki link reference <https://wiki.onap.org/display/DW/MDONS+Extension+in+R7>`_
208 Transport Slicing in Guilin release has implemented the following TN NSSMF functionality:
215 The Tranport Slicing implementation has made code changes in the following modules:
217 - AAI (Schema changes only)
225 Functional/Integration Test Cases
226 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
228 For integration test case and description of MDONS extension, refer to this
229 `following wiki-page <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_.
231 For integration test case and description of Transport Slicing:
233 - `Guilin Test plan <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_
234 - `Guilin E2E Network Slicing <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R7+Guilin>`_
236 Installation Procedure
237 ~~~~~~~~~~~~~~~~~~~~~~
239 For MDONS extension, the integration test environment is established to have ONAP instance with Guilin
240 release interfacing to 3rd party transport domain controllers. One controller
241 instance manages OpenROADM OTN topology and the other 2 instances manage TAPI
242 OTN topology. L0 infrastructure and WDM services are pre-provisioned to support
243 L1 topology discovery and OTN service orchestration from ONAP.
245 For Transport Slicing, the installation procedure is similar to that of the E2E
246 Network Slicing use case. In other words, we need to bring up the required modules
247 including SDC, SO, A&AI, UUI and OOF. We also need to configure these modules along
248 with the mandatory common modules such as DMaaP.
253 The testing procedure is described in:
255 - `Testing procedure for MDONS extension <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_
256 - `Testing procedure for Transport Slicing <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_
258 Update for Frankfurt release
259 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
261 In Frankfurt, we introduced two extensions in CCVPN use case. One is E-LINE service over OTN NNI handover, another is the
262 multi domain optical service which aims to provide end to end layer 1 service.
270 It is considered a typical scenario for operators to use OTN to interconnect its multiple transport network domains. Hence
271 the capabilities of orchestrating end-to-end E-LINE services across the domains over OTN is important for ONAP. When operating
272 with multiple domains with multi vendor solutions, it is also important to define and use standard and open
273 interfaces, such as the IETF ACTN-based transport `YANG models <https://tools.ietf.org/html/rfc8345>`_, as the southbound interface
274 of ONAP, in order to ensure interoperability. The SOTN NNI use-case aims to automate the design, service provision by independent
275 operational entities within a service provider network by delivering E-Line over OTN orchestration capabilities into ONAP. SOTN NNI
276 extends upon the CCVPN use-case by incorporating support for L1/L2 network management capabilities leveraging open standards & common
279 Frankfurt Scope and Impacted modules
280 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
282 The Frankfurt demonstration includes L1(OTN) and L2(ETH) Topology discovery from multiple domains controllers with in an operator
283 and provide VPN service provision in OTN and ETH network.
285 The ONAP components involved in this use case are: SDC, A&AI, UUI, SO, SDNC, OOF, MSB.
287 Functional Test Cases
288 ~~~~~~~~~~~~~~~~~~~~~
290 Usecase specific developments have been realized in SO, OOF, AAI, SDNC and UUI ONAP components..
295 SOTNVPNInfraService service design in SDC and distribute to AAI and SO.
298 All operation will be triggered by UUI, including service creation and termination,
299 link management and topology network display:
301 - `E-LINE over OTN Inter Domain Test Cases <https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases>`_
302 - `Testing status <https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status>`_
304 MDONS (Multi-Domain Optical Network Services)
305 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
310 The MDONS use-case aims to automate the design, activation & operations resulting
311 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.
313 Frankfurt Scope and Impacted modules
314 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
316 MDONS implementation for the Frankfurt release will incorporate the following:
317 - Design & modelling of optical services based on MEF L1 subscriber & operator properties
318 - E2E optical service workflow definitions for service instantiation & deletion
319 - UI portal with L1 service instantiation templates
320 - Optical Transport domain management (topology, resource onboarding) through standard models / APIs - OpenROADM, T-API
321 Impacted ONAP modules include: A&AI, SDC, SDN-C, SO, UUI
325 - `OpenROADM reference <https://github.com/OpenROADM/OpenROADM_MSA_Public>`_
326 - `ONF Transport-API (TAPI) <https://github.com/OpenNetworkingFoundation/TAPI>`_
327 - `MEF <https://wiki.mef.net/display/CESG/MEF+63+-+Subscriber+Layer+1+Service+Attributes>`_
329 Functional/Integration Test Cases
330 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
332 For integration test case and description, refer to this following
333 `wiki-page <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_.
335 Installation Procedure
336 ~~~~~~~~~~~~~~~~~~~~~~
338 The integration test environment is established to have ONAP instance with
339 Frankfurt release interfacing to 3rd party transport domain controllers.
340 One controller instance manages OpenROADM OTN topology and the other 2 instances
341 manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned
342 to support L1 topology discovery and OTN service orchestration from ONAP.
347 Test environment is described in
348 `Installation and Test Procedure <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_.
350 Update for Dublin release
351 ~~~~~~~~~~~~~~~~~~~~~~~~~
353 1. Service model optimization
355 In Dublin release,the design of CCVPN was optimized by having support of List type of Input in SDC.
356 During onboarding and design phase, one end to end service is created using SDC.
357 This service is composed of these two kinds of resources:
362 See the `Details of Targeted Service Template wiki page <https://wiki.onap.org/display/DW/Details+of+Targeted+Service+Template>`_
365 2. Closed Loop in bandwidth adjustment
366 Simulate alarm at the edge site branch and ONAP will execute close-loop automatically and trigger bandwidth to change higher.
369 Site can be add or delete according to the requirements
371 More information about:
373 - `CCVPN in Dublin release <https://wiki.onap.org/pages/viewpage.action?pageId=45296665>`_
374 - `Dublin test cases <https://wiki.onap.org/display/DW/CCVPN+Test+Cases+for+Dublin+Release>`_
375 - `CCVPN Test Status wiki page <https://wiki.onap.org/display/DW/CCVPN+Test+Status>`_
378 CCVPN integration testing coversed service design, service creation and
379 closed-loop bandwidth adjustments in Dublin release.
381 The service termination and service change will continue to be tested in E release.
382 During the integration testing, SDC, SO, SDC master branch are used which
383 includes the enhanced features for CCVPN use case.
385 Service used for CCVPN
386 ~~~~~~~~~~~~~~~~~~~~~~
388 - `SOTNVPNInfraService, SDWANVPNInfraService and SIteService <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_
389 - `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>`_
394 Cross-domain, cross-layer VPN (CCVPN) is one of the use cases of the ONAP
395 Casablanca release. This release demonstrates cross-operator ONAP orchestration
396 and interoperability with third party SDN controllers and enables cross-domain,
397 cross-layer and cross-operator service creation and assurance.
399 The demonstration includes two ONAP instances, one deployed by Vodafone and one
400 by China Mobile, both of which orchestrate the respective operator underlay OTN
401 networks and overlay SD-WAN networks and peer to each other for cross-operator
402 VPN service delivery.
404 `CCVPN Use Case Wiki Page <https://wiki.onap.org/display/DW/CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE>`_
406 The projects covered by this use case include: SDC, A&AI, UUI, SO, SDNC, OOF, Policy, DCAE(Holmes), External API, MSB
413 - `SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_
414 - `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>`_
418 - All operations will be triggered by UUI, including service creation and termination,
419 link management and topology network display.
422 See the `CCVPN Test Guide wiki page <https://wiki.onap.org/display/DW/CCVPN+Test+Guide>`_
425 Test Status and Plans
426 ~~~~~~~~~~~~~~~~~~~~~
428 - `All test case covered by this use case <https://wiki.onap.org/display/DW/CCVPN+Integration+Test+Case>`_
429 - `Test status <https://wiki.onap.org/display/DW/CCVPN++-Test+Status>`_
431 Known Issues and Resolutions
432 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
434 1) AAI-1923. Link Management, UUI can't delete the link to external onap otn domain.
436 For the manual steps provided by A&AI team, we should follow the steps as follow
437 the only way to delete is using the forceDeleteTool shell script in the graphadmin container.
438 First we will need to find the vertex id, you should be able to get the id by making the following GET request.
440 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete/esr-system-info/test-esr-system-info-id-val-0?format=raw
449 "node-type": "pserver",
450 "url": "/aai/v13/cloud-infrastructure/pservers/pserver/pserverid14503-as988q",
457 Same goes for the ext-aai-network:
459 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete?format=raw
461 Retrieve the id from the above output as that will be the vertex id that you want to remove.
463 Run the following command multiple times for both the esr-system-info and ext-aai-network:
467 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
469 From the above, remove the YOUR_ID_ANY_VALUE and VERTEX_ID with your info.
471 2) SDC-1955. Site service Distribution
473 To overcome the Service distribution, the SO catalog has to be populated with the model information of the services and resources.
474 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
475 b) Download the Csar from SDC thus generated.
476 c) copy the csar to SO sdc controller pod and bpmn pod
480 kubectl -n onap get pod|grep so
481 kubectl -n onap exec -it dev-so-so-sdc-controller-c949f5fbd-qhfbl /bin/sh
484 kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar dev-so-so-bpmn-infra-58796498cf-6pzmz:null/ASDC/1/service-Sdwanvpninfraservice-csar.csar
485 kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar dev-so-so-bpmn-infra-58796498cf-6pzmz:ASDC/1/service-Sdwanvpninfraservice-csar.csar
487 d) populate model information to SO db: the db script example can be seen in
488 https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing
490 The same would also be applicable for the integration of the client to create the service and get the details.
491 Currently the testing has been performed using the postman calls to the corresponding APIs.
493 3) SDC-1955 & SDC-1958. Site service parsing Error
495 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
496 a) Make an available csar file for CCVPN use case.
497 b) Replace uuid of available files with what existing in SDC.
498 c) Put available csar files in UUI local path (/home/uui).
500 4) SO docker branch 1.3.5 has fixes for the issues 1SO-1248
502 After SDC distribution success, copy all csar files from so-sdc-controller:
504 - connect to so-sdc-controller ( eg: kubectl.exe exec -it -n onap dev-so-so-sdc-controller-77df99bbc9-stqdz /bin/sh )
505 - find out all csar files ( eg: find / -name "\*.csar" ), the csar files should
506 be in this path: /app/null/ASDC/ ( eg: /app/null/ASDC/1/service-Sotnvpninfraservice-csar.csar )
507 - exit from the so-sdc-controller ( eg: exit )
508 - 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 )
510 Copy csar files, which got from so-sdc-controller, to so-bpmn-infra:
512 - 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 )
513 - check the /app/ASDC directory, if doesn't exist, create it ( eg: mkdir /app/ASDC -p )
514 - exit from the so-bpmn-infra ( eg: exit )
515 - 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 )