Integration Test Cases - MDONS Extension

Owned by Xin Miao (Unlicensed)
Last updated: Oct 28, 2020
3 min read



1.  Introduction

MDONS use case was proposed in ONAP Frankfurt release. Extension work in OOF support, asynchronous OpenRoadM service activation response handling and closed loop sub-use cases and scenario was introduced in Guilin release. Associated test cases are covered in the following sessions on this page. 

INT-1659: MDONS Extnesion: Integration TestClosed

2. MDONS  Primary Test Cases in R6

     The test cases and environment set up can be taken as basic preparation for MDONS Extension test.  

3. Asynchronous Service Response Handling (ASRH)

3.1  Response handling Upon Successful Open RoadM OTN Service Activation

Test NO:

TEST-01

Project:

OTN Service LCM 

Sub-project:

OpenRoadM OTN Service Creation  

Objective:

The OpenRoadM OTN services creation status changed from pending to successful upon service activation is succeeded. 

Pre-condition:

  1. OpenRoadM domain controller (Fujitsu VNC) is running and OpenRoadM (MSA) topology has been discovered and loaded in ONAP.

  2. The OTN services creation request is pending because synchronous response indicates that a following async-response will be received by ONAP. 

Test steps:

  1. Administrator login to ONAP Use case UI.

  2. Submit a OpenRoadM OTN service creation request 

  3. Notice service creation is pending from UUI.

  4. Send a OTN service activation request from Postman or Restclient to the domain controller (VNC) by call its NB API. 

  5. Upon an activation success notification respond back from VNC to ONAP (SDNC)

  6. The OTN service status become successful at UUI.

Test Result:

  1. The OpenRoadM OTN  service creation become successful.



Observation:

  1. Check UUI, we can find the associated OTN service creation status changed from pending to successful.

4.  MDONS OOF Support

4.1  Inter Domain Link/Path Selection at TAPI OTN Service Creation

Test NO:

TEST-02

Project:

OTN Service LCM 

Sub-project:

TAPI OTN Service Creation  

Objective:

A cross domain OTN Service is created by calling OOF Interface at inter domain link selection.

Pre-condition:

  1. More than one inter domain links (IDLs) have already been provisioned in ONAP/AAI between 2 domains.   

Test steps:

  1. Administrator login to ONAP Usecase UI.

  2. Create an  OTN service between 2 network interface (TAPI UNI) end points which belong 2 different domains. 

  3. Notice that one of the IDLs is selected for the OTN service instance created.

Test Result:

  1. An OTN  service is successfully created across two domains controlled by two domain controllers respectively.



Observation:

  1. Check from UUI, we can find the cross domain OTN service is created with an appropriate IDL associated with it.

5.  Closed Loop

5.1  Different IDL and Domain OTN Services Associated An Existing Access OTN Service  After Node Down Alarm Raised 

Test NO:

TEST-03

Project:

MDONS Closed Loop 

Sub-project:

Cross Domain OTN Service Re-provisioning   

Objective:

Cross domain OTN service re-provision is supported automatically upon node down alarm(s) raised through 

VNC to close the loop. 

Pre-condition:

  1. More than one inter domain links (IDLs) have already been provisioned in ONAP/AAI between 2 domains. 

  2. Cross domain OTN service(s) has been created. 

  3. VES collector, Holmes and Apex Policy Engine are deployed in ONAP cluster. 

  4. Domain controllers (VNC) are configured to send out VES fault event to ONAP/DCAE (VES Collector).

Test steps:

  1. Deploy predefined alarm process rule at Holmes.

  2. Configure and Deploy predefined Apex operation policy at APEX. 

  3. Generate alarm from SB NE simulator (for the time being).

  4. Notice that associated IDL goes down in ONAP by running AAI query.

  5. Another  IDL is selected for the OTN service instance.

  6. Two original domain services associated with the OTN service are replaced by two new domain services. 

Test Result:

  1. An OTN  service instance is successfully re-provisioned.



Observation:

  1. Check from UUI, we can find a different IDL and two new domain services are associated with the existing OTN service instance.

Note: