Versions Compared

Old Version 36

changes.mady.by.user Michela Bevilacqua

Saved on

compared with

New Version 37

changes.mady.by.user Raj Gumma

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Table of Contents
Image Removed

Overview:

The Netconf configuration over TLS use case consists The E2E integration test consists of three main parts:

  • SO will implement two more steps in workflow CONFIG-ASSIGN and CONFIGURE step.
  • CDS Blueprint Processor will implement the mount, configure and un-mount requests to SDNC after getting CONFIGURE request from SO. The processor currently has the ability to read a blueprint from archive and process it.
  • SDNC will load client cert , trusted certs and private key at deployment time. ODL should also be upgraded to Flourine SR2 version to serve above requests. The upgrade is being tracked as part of SDNC-555

JIRAs:

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCCSDK-926

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyCCSDK-1023

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDNC-556

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySDNC-621

Jira Legacy
serverSystem Jira
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keySO-1506

Jira LegacyserverSystem Jiracolumnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutionserverId4733707d-2057-3a0f-ae5e-4fd8aff50176keyINT-885


Gliffy
size300
nameSDC-service-distribution
pagePin5

Image Added

Image Added


Deployment:

Test environment requirements for the test cases:

  • xNF simulator for test cases:  PNF Simulator with TLS & YANG support.
  • Rest Client simulator.
  • SO with Config-Assign and Configure steps implemented in workflows.
  • CDS Blueprint processor enhanced so that it can send mount, configure and un-mount rest request to SDNC.
  • SDNC enhanced with ODL flourine SR2 and also capable to import client and trusted certificate and private key at deployment time.

This environment can be set up by following the steps below.

  1. Repo : Yet to update
  2. RUN : Yet to update

Use Case preconditions:

    • xNF simulator.
    • Rest Client sim.

E2E Netconf config over TLS Sequence Diagram

Image Removed

High Level End-to-End feature integration

Testcases

Test cases :


#Test CaseDescription
Status4Connect SDN-C and PNF Simulator for configuration step5E2E test case for NETCONF over TLS6

Successful flow: CONFIG-ASSIGN and CONFIGURE steps will conclude as expected, and the desired configuration will be applied to the PNF; successful outcome

Detailed Description End-to-End Feature Integration Testcases :

Test Case ID

Netconf_TLS_E2E_01

Test Case Name

SO sends CONFIG-ASSIGN and CONFIGURE request to SS-API

DescriptionEnsure that PNF_READY notification is received by SO from simulated environment then SO sends CONFIG-ASSIGN request to SS-APIReleaseDublinPre-conditions

SO should be waiting for PNF_READY notification after registration process and fully configured as per registration process.

Follow the 5G - PNF PnP - Integration Test Cases T01, T02, T03, T04 to complete the PNF registration and waiting for the PNF_READY notification.

Testing StepsStepsExpected Result
  1. Send PNF_READY to SO
  2. SO will send CONFIG-ASSIGN to SS-API
  3. Receive it and Check if it is correct
  4. Send OK response to SO
  5. SO will send CONFIGURE request to SS-API
  6. Receive it and check if it is correct
  7. Send OK response to SO

The SO accepted the "PNF_READY" Notification.

and sends out the CONFIG-ASSIGN request to SS-API

and receive an OK response from SS-API

Conclusion (Pass /Fail)Testing LabTest Case IDNetconf_TLS_E2E_02Test Case Name

Sends CONFIGURE request to SS-API

DescriptionIn this simulated CONFIG-ASSIGN request will be sent to SS-API and response will be picked to check if response is OK.ReleaseDublinPre-conditions

Blueprint processor should have access to correct blueprint in archive to process it.

SDN-C should be available

Testing Steps

StepsExpected Result
  • Sends CONFIGURE request to SS-API
  • SS-API will receive it
    • SS-API send CONFIGURE request to Blueprint Processor component.
  • Component sends Mount to SDN-C
  • Receive this request read it if it is correct
    • Send OK 200 response
  • Blueprint processor sends configuration request to SDN-C
  • Receive this request read it if it is correct
    • SDN-C sends OK 200 response
  • Blueprint processor sends un-mount request to SDN-C
  • Receive this request read it if it is correct
  • SDN-C sends OK 200 response

    • Check for mount, configure and un-mount messages triggered by the Blueprint processor component.

    Verify that messages are valid and reflect all the expected parameters.

    Conclusion (Pass /Fail)Testing LabTest Case IDNetconf_TLS_E2E_03Test Case Name

    Check SDN-C has client cert, private key and trusted certs setup at deployment

    DescriptionSDN-C configure client cert, private key and trusted certs and deployment time. This test case verifies if all certificates are configured fine.ReleaseDublinPre-conditions

    SDN-C should be up and running successfully

    Testing Steps

    StepsExpected Result
    1. Send GET request from rest client to SDN-C for key store
    2. Verify if it has all necessary entries for Client cert, trusted certs and private key.

    Get request should get all certs and private key successfully.

    Conclusion (Pass /Fail)Testing LabTest Case IDNetconf_TLS_E2E_04Test Case Name

    Connect SDN-C and PNF simulator for configuration step

    DescriptionSDN-C/ODL will send mount , configure and un-mount request to PNF simulator and check if PNF simulator is configured successfully.ReleaseDublinPre-conditions

    PNF simulator should be up and running with TLS port listening. It should also be configured with Yang Models necessary for configuration request.

    Testing Steps

    StepsExpected Result
  • Send mount request to SDN-C from rest client.
  • Check for 200 OK response
  • Send GET request for mount
    • Check data from GET response
  • Send configuration request to SDN-C from rest client.
  • Check for 200 OK response
  • Send GET request for configuration
    • Check data from GET response
  • Send un-mount request to SDN-C from rest client
  • check for 200 OK response
  • Send GET request for un-mount
    • Check data from GET response

    Get response should give correct result for mount, configure and un-mount.

    Conclusion (Pass /Fail)Testing LabTest Case IDNetconf_TLS_E2E_05
    Reference
    1
    After PNF_READY, SO sends CONFIG-ASSIGN and CONFIGURE request to Self Service API (SS-API)2SO Sends CONFIGURE request to SS-API3Verify SDN-C have client cert, private key and trusted certs setup at deployment
    Create and distribute service which contains PNFVerify distribution and ingestion of PNF service csar to VID, AAI & SO.5G - PNF Onboarding Test Cases and Status : PNF-OB-5
    2Waiting for PNFReadyVerification if PNF PnP functionality within SO is waiting for PNFReady to be published by PRH.5G - PNF PnP -WaitingforPNFReady
    3

    PNF registration accepted

    Verification if PNF resource registration is done properly

    		5G : Configuration with NETCONF - SO triggers Configuration
    4Send Configuration with NETCONF over TLSVerify the configuration is sent to the PNF with NETCONF5G : Configuration with NETCONF - Success Flow


    Detailed Description End-to-End Feature Integration Testcases :


    Test Case ID

    Anchor
    SO triggers Configuration
    SO triggers Configuration

    Netconf_TLS_E2E_03

    Test Case Name

    E2E test case for NETCONF over TLS

    DescriptionEnsure that PNF_READY notification is received by SO from simulated environment then SO sends CONFIG-ASSIGN, CONFIGURE request to SS-API
    ReleaseDublin
    Pre-conditionsSO should be waiting for PNF_READY notification after registration process and fully configured as per registration process. Blueprint archive should be configured for correct blueprint. SDNC should be installed successfully and PNF simulator should be running with TLS support.
    Testing Steps


    StepsExpected Result
    1. Send PNF_READY to SO(This step will trigger a run to SS-API, BP component, SDNC and PNF simulator)
    2. Send SSH mount/connect request to SDNC/ODL using rest client.
    3. Send GET request for configuration to get configuration, set in step 1.
    4. Verify received configuration is correct.
    		Get response should give correct result for configure



    Conclusion (Pass /Fail)
    Testing Lab



    Test Case ID

    Anchor
    Successful flow
    Successful flow

    		Netconf_TLS_E2E_0604
    Test Case Name

    Successful flow

    DescriptionSteps assignConfig and deployConfig will conclude as expected, and the desired configuration will be applied to the PNF
    Release

    Dublin

    Pre-conditions

    Valid PNF
    Valid blueprint
    SO is primed and post PNF registration stage
    ODL instance is installed and available

    Testing Steps




    StepsExpected Result

    1. SO sends a request to perform action assignConfig

    Code Block
    languageyml
    blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

    2. SS-API forwards the request to BP, that will load the blueprint, execute the action specified, prepare the configlet, persist it and return a successful message to SO

    3. SO recognizes the success message and sends a request to perfom action deployConfig

    Code Block
    languageyml
    blueprintName: String
blueprintVersion: Integer
action: String
pnf-name: String
pnf-ip: String

    4. SS-API forwards the request to Blueprint Processor, that will load the blueprint, execute the action specified, retrieve the configlet from the persistence, connect to ODL, send the configlet(s) to the PNF and return a successful message to SO



    Conclusion (Pass /Fail)
    Testing Lab?


    Information:


    Next Step(s):