Content Comparison

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 portal?select ‘UUI-biz’ to entry use 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.

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 portal?select ‘UUI-biz’ to entry use case Usecase UI.

  2. Submit Create an  OTN service between 2 network interface (NITAPI UNI) end points which belong 2 different creation requestdomains. 

  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.

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 APEAPEX. 

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

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

  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:

•   Refer to the following pages for details about MDONS Close Loop setup and artifacts:
  • MDONS Close Loop Use Case