1 .. This work is licensed under a Creative Commons Attribution 4.0
2 International License. http://creativecommons.org/licenses/by/4.0
6 CCVPN (Cross Domain and Cross Layer VPN)
7 ----------------------------------------
9 Update for Guilin Release
10 ~~~~~~~~~~~~~~~~~~~~~~~~~
12 In Guilin Release, **MDONS** Extension feature is introduced.
14 In addition to the MDONS extension, CCVPN has also developed an
15 IETF/ACTN-based Transport Slicing solution (REQ-347). This development
16 enabled ONAP to offer the TN NSSMF functionality, which was used by
17 the E2E Network Slicing use case (REQ-342). The solution was built
18 upon the existing IETF/ACTN E-LINE over OTN NNI feature developed in Frankfurt release.
20 Guilin Scope and Impacted modules
21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
22 MDONS Extension implementation for the Frankfurt release will incorporate the following:
24 - Support Asynchronous OpenRoadM OTN service activation notification handling
25 - Add OOF support for inter domain link/path selection
26 - Support Closed Loop sub-use case
27 Impacted ONAP modules include: OOF, SDN-C, SO and Holmes
29 `Wiki link reference <https://wiki.onap.org/display/DW/MDONS+Extension+in+R7>`_
31 Transport Slicing in Guilin release has implemented the following TN NSSMF functionality:
38 The Tranport Slicing implementation has made code changes in the following modules:
40 - AAI (Schema changes only)
48 Functional/Integration Test Cases
49 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
51 For integration test case and description of MDONS extension, refer to this
52 `following wiki-page <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_.
54 For integration test case and description of Transport Slicing:
56 - `Guilin Test plan <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_
57 - `Guilin E2E Network Slicing <https://wiki.onap.org/display/DW/E2E+Network+Slicing+Use+Case+in+R7+Guilin>`_
59 Installation Procedure
60 ~~~~~~~~~~~~~~~~~~~~~~
62 For MDONS extension, the integration test environment is established to have ONAP instance with Guilin
63 release interfacing to 3rd party transport domain controllers. One controller
64 instance manages OpenROADM OTN topology and the other 2 instances manage TAPI
65 OTN topology. L0 infrastructure and WDM services are pre-provisioned to support
66 L1 topology discovery and OTN service orchestration from ONAP.
68 For Transport Slicing, the installation procedure is similar to that of the E2E
69 Network Slicing use case. In other words, we need to bring up the required modules
70 including SDC, SO, A&AI, UUI and OOF. We also need to configure these modules along
71 with the mandatory common modules such as DMaaP.
76 The testing procedure is described in:
78 - `Testing procedure for MDONS extension <https://wiki.onap.org/display/DW/Integration+Test+Cases+-+MDONS+Extension>`_
79 - `Testing procedure for Transport Slicing <https://wiki.onap.org/display/DW/CCVPN+-+Transport+Slicing+integration+test+plan+for+Guilin+release>`_
81 Update for Frankfurt release
82 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
84 In Frankfurt, we introduced two extensions in CCVPN use case. One is E-LINE service over OTN NNI handover, another is the
85 multi domain optical service which aims to provide end to end layer 1 service.
93 It is considered a typical scenario for operators to use OTN to interconnect its multiple transport network domains. Hence
94 the capabilities of orchestrating end-to-end E-LINE services across the domains over OTN is important for ONAP. When operating
95 with multiple domains with multi vendor solutions, it is also important to define and use standard and open
96 interfaces, such as the IETF ACTN-based transport `YANG models <https://tools.ietf.org/html/rfc8345>`_, as the southbound interface
97 of ONAP, in order to ensure interoperability. The SOTN NNI use-case aims to automate the design, service provision by independent
98 operational entities within a service provider network by delivering E-Line over OTN orchestration capabilities into ONAP. SOTN NNI
99 extends upon the CCVPN use-case by incorporating support for L1/L2 network management capabilities leveraging open standards & common
102 Frankfurt Scope and Impacted modules
103 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
105 The Frankfurt demonstration includes L1(OTN) and L2(ETH) Topology discovery from multiple domains controllers with in an operator
106 and provide VPN service provision in OTN and ETH network.
108 The ONAP components involved in this use case are: SDC, A&AI, UUI, SO, SDNC, OOF, MSB.
110 Functional Test Cases
111 ~~~~~~~~~~~~~~~~~~~~~
113 Usecase specific developments have been realized in SO, OOF, AAI, SDNC and UUI ONAP components..
115 See the `wiki <https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases>`_
121 SOTNVPNInfraService service design in SDC and distribute to AAI and SO.
124 All operation will be triggered by UUI, including service creation and termination,
125 link management and topology network display:
127 - `E-LINE over OTN Inter Doamin Test Cases <https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases>`_
128 - `Testing status <https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status>`_
130 MDONS (Multi-Domain Optical Network Services)
131 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
136 The MDONS use-case aims to automate the design, activation & operations resulting
137 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.
139 Frankfurt Scope and Impacted modules
140 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
142 MDONS implementation for the Frankfurt release will incorporate the following:
143 - Design & modelling of optical services based on MEF L1 subscriber & operator properties
144 - E2E optical service workflow definitions for service instantiation & deletion
145 - UI portal with L1 service instantiation templates
146 - Optical Transport domain management (topology, resource onboarding) through standard models / APIs - OpenROADM, T-API
147 Impacted ONAP modules include: A&AI, SDC, SDN-C, SO, UUI
151 - `OpenROADM reference <https://github.com/OpenROADM/OpenROADM_MSA_Public>`_
152 - `ONF Transport-API (TAPI) <https://github.com/OpenNetworkingFoundation/TAPI>`_
153 - `MEF <https://wiki.mef.net/display/CESG/MEF+63+-+Subscriber+Layer+1+Service+Attributes>`_
155 Functional/Integration Test Cases
156 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
158 For integration test case and description, refer to this following
159 `wiki-page <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_.
161 Installation Procedure
162 ~~~~~~~~~~~~~~~~~~~~~~
164 The integration test environment is established to have ONAP instance with
165 Frankfurt release interfacing to 3rd party transport domain controllers.
166 One controller instance manages OpenROADM OTN topology and the other 2 instances
167 manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned
168 to support L1 topology discovery and OTN service orchestration from ONAP.
173 Test environment is described in
174 `Installation and Test Procedure <https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case>`_.
176 Update for Dublin release
177 ~~~~~~~~~~~~~~~~~~~~~~~~~
179 1. Service model optimization
181 In Dublin release,the design of CCVPN was optimized by having support of List type of Input in SDC.
182 During onboarding and design phase, one end to end service is created using SDC. This service is
183 composed of these two kinds of resources:
186 See the `wiki <https://wiki.onap.org/display/DW/Details+of+Targeted+Service+Template>`_ for details.
188 2. Closed Loop in bandwidth adjustment
189 Simulate alarm at the edge site branch and ONAP will execute close-loop automatically and trigger bandwidth to change higher.
192 Site can be add or delete according to the requirements
194 More information about:
196 - `CCVPN in Dublin release <https://wiki.onap.org/pages/viewpage.action?pageId=45296665>`_
197 - `Dublin test cases <https://wiki.onap.org/display/DW/CCVPN+Test+Cases+for+Dublin+Release>`_
198 - `test status <https://wiki.onap.org/display/DW/CCVPN+Test+Status>`_
201 CCVPN integration testing coversed service design, service creation and
202 closed-loop bandwidth adjustments in Dublin release.
204 The service termination and service change will continue to be tested in E release.
205 During the integration testing, SDC, SO, SDC master branch are used which
206 includes the enhanced features for CCVPN use case.
208 Service used for CCVPN
209 ~~~~~~~~~~~~~~~~~~~~~~
211 - `SOTNVPNInfraService, SDWANVPNInfraService and SIteService <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_
212 - `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>`_
217 Cross-domain, cross-layer VPN (CCVPN) is one of the use cases of the ONAP
218 Casablanca release. This release demonstrates cross-operator ONAP orchestration
219 and interoperability with third party SDN controllers and enables cross-domain,
220 cross-layer and cross-operator service creation and assurance.
222 The demonstration includes two ONAP instances, one deployed by Vodafone and one
223 by China Mobile, both of which orchestrate the respective operator underlay OTN
224 networks and overlay SD-WAN networks and peer to each other for cross-operator
225 VPN service delivery.
227 `CCVPN Use Case Wiki Page <https://wiki.onap.org/display/DW/CCVPN%28Cross+Domain+and+Cross+Layer+VPN%29+USE+CASE>`_
229 The projects covered by this use case include: SDC, A&AI, UUI, SO, SDNC, OOF, Policy, DCAE(Holmes), External API, MSB
236 - `SOTNVPNInfraService, SDWANVPNInfraService and SIteService service Design steps <https://wiki.onap.org/display/DW/CCVPN+Service+Design>`_
237 - `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>`_
241 - All operations will be triggered by UUI, including service creation and termination,
242 link management and topology network display.
245 See the `wiki <https://wiki.onap.org/display/DW/CCVPN+Test+Guide>`_ for details.
247 Test Status and Plans
248 ~~~~~~~~~~~~~~~~~~~~~
250 - `All test case covered by this use case <https://wiki.onap.org/display/DW/CCVPN+Integration+Test+Case>`_
251 - `Test status <https://wiki.onap.org/display/DW/CCVPN++-Test+Status>`_
253 Known Issues and Resolutions
254 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
256 1) AAI-1923. Link Management, UUI can't delete the link to external onap otn domain.
258 For the manual steps provided by A&AI team, we should follow the steps as follow
259 the only way to delete is using the forceDeleteTool shell script in the graphadmin container.
260 First we will need to find the vertex id, you should be able to get the id by making the following GET request.
262 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete/esr-system-info/test-esr-system-info-id-val-0?format=raw
271 "node-type": "pserver",
272 "url": "/aai/v13/cloud-infrastructure/pservers/pserver/pserverid14503-as988q",
279 Same goes for the ext-aai-network:
281 GET /aai/v14/network/ext-aai-networks/ext-aai-network/createAndDelete?format=raw
283 Retrieve the id from the above output as that will be the vertex id that you want to remove.
285 Run the following command multiple times for both the esr-system-info and ext-aai-network:
289 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
291 From the above, remove the YOUR_ID_ANY_VALUE and VERTEX_ID with your info.
293 2) SDC-1955. Site service Distribution
295 To overcome the Service distribution, the SO catalog has to be populated with the model information of the services and resources.
296 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
297 b) Download the Csar from SDC thus generated.
298 c) copy the csar to SO sdc controller pod and bpmn pod
302 kubectl -n onap get pod|grep so
303 kubectl -n onap exec -it dev-so-so-sdc-controller-c949f5fbd-qhfbl /bin/sh
306 kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar dev-so-so-bpmn-infra-58796498cf-6pzmz:null/ASDC/1/service-Sdwanvpninfraservice-csar.csar
307 kubectl -n onap cp service-Sdwanvpninfraservice-csar.csar dev-so-so-bpmn-infra-58796498cf-6pzmz:ASDC/1/service-Sdwanvpninfraservice-csar.csar
309 d) populate model information to SO db: the db script example can be seen in
310 https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing
312 The same would also be applicable for the integration of the client to create the service and get the details.
313 Currently the testing has been performed using the postman calls to the corresponding APIs.
315 3) SDC-1955 & SDC-1958. Site service parsing Error
317 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
318 a) Make an available csar file for CCVPN use case.
319 b) Replace uuid of available files with what existing in SDC.
320 c) Put available csar files in UUI local path (/home/uui).
322 4) SO docker branch 1.3.5 has fixes for the issues 1SO-1248
324 After SDC distribution success, copy all csar files from so-sdc-controller:
326 - connect to so-sdc-controller ( eg: kubectl.exe exec -it -n onap dev-so-so-sdc-controller-77df99bbc9-stqdz /bin/sh )
327 - find out all csar files ( eg: find / -name "\*.csar" ), the csar files should
328 be in this path: /app/null/ASDC/ ( eg: /app/null/ASDC/1/service-Sotnvpninfraservice-csar.csar )
329 - exit from the so-sdc-controller ( eg: exit )
330 - 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 )
332 Copy csar files, which got from so-sdc-controller, to so-bpmn-infra:
334 - 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 )
335 - check the /app/ASDC directory, if doesn't exist, create it ( eg: mkdir /app/ASDC -p )
336 - exit from the so-bpmn-infra ( eg: exit )
337 - 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 )