Versions Compared

Key

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

Table of Contents

Table of Contents

Sub pages

Children Display

Scope

This wiki describes the test environment for OAM specific test cases focusing on  D-Release Closed Loop O-RU recovery use case.

Jira
serverORAN Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId5ec52304-b77c-3ce7-af6a-112cb13e6008
keyOAM-193

Components

The following Component diagram shows the most relevant components and their associations from O-RAN-SC OAM project point of view.

The different software components can be deployed with Docker-Compose or Kubernetes technologies. 

As O-RAN Alliance targets IPv6 please ensure the Docker IPv6 functionality is enabled (see O-RAN-SC Documentation Docker: Enable IPv6) or use Kubernetes version 1.19 or higher.

Diagram

Please see Closed loop use case

Descriptions

O-RU - NETCONF-Server-OFH

For D-Release the O-RU operates in "hybrid" mode. This means that the O-RU exposes O-RAN OpenFronthaul NETCONF/YANG interface directly to the OAM functions of the SMO. 

For OAM test environment it is recommended to use the O-RU FH simulation from O-RAN-SC Sim project. The docker imager can be loaded directly from O-RAN-SC Nexus (nexus3.o-ran-sc.org:10004/o-ran-sc/nts-ng-o-ran-ru-fh:1.2.3). 

The simulation must be configured in a way that is support NETCONF call-home to the SMO-OAM-Controller and supports NETCONF <create-subscriptions/> RPC for stream "NETCONF".

The simulation must not expose any VES messages.

Depending on the OAM controller capabilities TLS certs of the O-RU must be configured at the OAM-Controller.

//TODO:add config CURL for O-RU

The following protocols from O-RU to OAM controller are under test:

  • NETCONF-Callhome/SSH/IPv4
  • NETCONF-Callhome/TLS/IPv4
  • NETCONF-Callhome/SSH/IPv6
  • NETCONF-Callhome/TLS/IPv6
  • NETCONF/SSH/IPV4 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
  • NETCONF/TLS/IPv4  for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
  • NETCONF/SSH/IPV6 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
  • NETCONF/TLS/IPv6  for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)

O-DU - NETCONF-Server-O1

For D-Release the O-DU operates in "hybrid" mode. This means that the O-DU does not expose any management plane functions of connected O-RUs. To reduce the development effort on O-DU it was decided in RSAC meetings that the O-DU at minimum exposes the o-ran-sc-hello-world.yang (see

Jira
serverORAN Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId5ec52304-b77c-3ce7-af6a-112cb13e6008
keyOAM-169
 and 
Jira
serverORAN Jira
serverId5ec52304-b77c-3ce7-af6a-112cb13e6008
keyODUHIGH-322
).

For OAM test environment it is recommended to use the O-DU O1 simulation from O-RAN-SC Sim project. The docker imager can be loaded directly from O-RAN-SC Nexus (nexus3.o-ran-sc.org:10004/o-ran-sc/nts-ng-o-ran-du:1.2.3). 

The simulation must be configured in a way that is support NETCONF for configuration management only and VES for heartbeat, fault and pnfRegistration. 

Depending on the OAM controller capabilities TLS certs of the O-DU must be configured at the OAM-Controller.

//TODO:add config CURL for O-DU

The following protocols from O-RU to OAM controller are under test:

  • VES:pnfRegistration https/IPv4
  • VES:heartbeat https/IPv4
  • VES:fault https/IPv4
  • VES:pnfRegistration https/IPv6
  • VES:heartbeat https/IPv6
  • VES:fault https/IPv6
  • NETCONF/SSH/IPV4 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
  • NETCONF/TLS/IPv4  for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
  • NETCONF/SSH/IPV6 for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)
  • NETCONF/TLS/IPv6  for all NETCONF operations (but mainly GET, GET-CONFIG, EDIT-CONFIG)

OAM Controller

For D-Release the OAM controller provides a NETCONF client for SSH and/or TLS, a RESCONF server, and providers and listeners to the message router.

For OAM test environment it is recommended to use the ONAP CCSDK/SDNC/SDN-R in combination with KeyCloak as centralized user management. The docker imager can be loaded directly from ONAP Nexus (nexus3.onap.org:10001/onap/sdnc-image:2.1.5) and from KeyCloak (quay.io/keycloak/keycloak:12.0.4)

The new functionalities for D-Release are:

  • to convert NETCONF call-home into VES:pnfRegistration (JIRA | CCSDK-3160)
  • to convert NETCONF notification by O-RU/alarm-notify into VES:fault (JIRA | CCSDK-3158)
  • Gui-Cut-Through for O-RUs

The following test cases should be performed using a centralized user management based on KeyCloak.

  • O-RU/NETCONF-Callhome/SSH/IPv4 → VES:pnfRegistration to message router
  • O-RU/NETCONF-Callhome/TLS/IPv4 → VES:pnfRegistration to message router
  • O-RU/NETCONF-Callhome/SSH/IPv6 → VES:pnfRegistration to message router
  • O-RU/NETCONF-Callhome/TLS/IPv6 → VES:pnfRegistration to message router
  • O-RU/NETCONF-Notification/SSH/IPv4/alarm-notifiy → VES:fault to message router 
  • O-RU/NETCONF-Notification/TLS/IPv4/alarm-notifiy → VES:fault to message router 
  • O-RU/NETCONF-Notification/SSH/IPv6/alarm-notifiy → VES:fault to message router 
  • O-RU/NETCONF-Notification/TSL/IPv6/alarm-notifiy → VES:fault to message router 
  • VES:pnfRegistration from message router → O-DU/NETCONF/SSH/IPv4/<hello/>
  • VES:pnfRegistration from message router → O-DU/NETCONF/TLS/IPv4/<hello/>
  • VES:pnfRegistration from message router → O-DU/NETCONF/SSH/IPv6/<hello/>
  • VES:pnfRegistration from message router → O-DU/NETCONF/TSL/IPv6/<hello/>
  • RESTCONF/HTTPS-GET/RESTCONF/IPv4 → O-DU/NETCONF/SSH/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-GET/RESTCONF/IPv4 → O-DU/NETCONF/TLS/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-GET/RESTCONF/IPv4 → O-DU/NETCONF/SSH/IPv6/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-GET/RESTCONF/IPv4 → O-DU/NETCONF/TLS/IPv6/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-GET/RESTCONF/IPv6 → O-DU/NETCONF/SSH/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-GET/RESTCONF/IPv6 → O-DU/NETCONF/TLS/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-GET/RESTCONF/IPv6 → O-DU/NETCONF/SSH/IPv6/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-GET/RESTCONF/IPv6 → O-DU/NETCONF/TLS/IPv6/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv4 → O-DU/NETCONF/SSH/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv4 → O-DU/NETCONF/TLS/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv4 → O-DU/NETCONF/SSH/IPv6/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv4 → O-DU/NETCONF/TLS/IPv6/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv6 → O-DU/NETCONF/SSH/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv6 → O-DU/NETCONF/TLS/IPv4/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv6 → O-DU/NETCONF/SSH/IPv6/<get-config/>/hello-world.yang
  • RESTCONF/HTTPS-PUT/RESTCONF/IPv6 → O-DU/NETCONF/TLS/IPv6/<get-config/>/hello-world.yang
  • Gui-Cut-Through to O-RUs

VES Collector

There are no new functions required for the VES Collector. The regression tests are covered by test cases mentioned above. 

For OAM test environment it is recommended to use the ONAP DCAE VES-Collector. The docker imager can be loaded directly from ONAP Nexus (nexus3.onap.org:10001/onap/org.onap.dcaegen2.collectors.ves.vescollector:1.8.0).

Message Router

There are no new functions required for the VES Collector. The regression tests are covered by test cases mentioned above. 

For OAM test environment it is recommended to use the ONAP DMaaP. The docker imager can be loaded directly from ONAP Nexus (nexus3.onap.org:10001/onap/dmaap/dmaap-mr:1.1.18).

For manual checks of activities on the Message Router a REST client is recommended (e.g. PostMan, vsCode with REST-client extension, Browser-RestClient-extensions, ....)

Test Networks

it is recommended to run the different components in different networks for security and responsibility reasons.

PlantUML Macro
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 
' Copyright 2021 highstreet technologies USA Corp.
' This work is licensed under a Creative Commons Attribution 4.0 International License.
' SPDX-License-Identifier: CC-BY-4.0
' https://creativecommons.org/licenses/by/4.0/deed.en

@startuml o-ran-sc-d-test-networks

' Diagram 
title 
  Use case Networks
end title

nwdiag {

  network DMZ {
    address = "172.30.0.0/16"
    color = "blue"

  internet [shape = cloud; description = "Internet\nOther Servcies\nDNS; DHCP; NTP; Acumos, etc"; color = "lightgrey"];
    Management_Switches [description = "      <&aperture*4>\nManagement\nSwitches"];
    gateway  [address = "gateway\n10G-1"; description = "  <&cog*4>\n Gateway"];
    identity [address = "identity\n10G-1"; description = " <&cog*4>\nIdentity"];
  }
  
  network SMO {
    address = "172.40.0.0/16\n2001:db8:1:1::/64"
    color = "yellow"
   
    gateway [address = "gateway\n10G-2"];
    topology [address = "topology\n10G-1"; description = "   <&cog*4>\nTopology"];
    dmaap   [address = "dmaap\n10G-1"; description = " <&cog*4>\nDMaaP"];
    sdnrdb [address = "sdnrdb\n10G-1"; description = "   <&cog*4>\nSDN-R-DB"];
    sdnr [address = "sdnr\n10G-1"; description = " <&cog*4>\nSDN-R"];
    ves     [address = "ves-collector\n10G-1"; description = "      <&cog*4>\nVES-Collector"];
  }

  network OAM {
    address = "172.50.0.0/16\n2001:db8:1:1::/64"
    color = "pink"

    ves  [address = "ves-collector\n100G-2"];
    sdnr [address = "sdnr\n100G-2"];
    oam  [description = "     <&aperture*4>\nOAM Switch"];
    nfs [shape = cloud; description = "Network Functions\ncNF; vNF; pNF; etc"];
  }
}

' End Diagram
' Format

left footer 
  <img:https://media-exp1.licdn.com/dms/image/C560BAQH0qSJJi67N4g/company-logo_200_200/0/1606867328974?e=2159024400&v=beta&t=OybMqHsK24YCp_WeGC10qJWJp-tsHu2GnjuF5gEeGSM{scale=0.2}>  Copyright 2021 highstreet technologies USA Corp.
  .              This work is licensed under a Creative Commons Attribution 4.0 International License.
  .              SPDX-License-Identifier: CC-BY-4.0
  .              2021-04-18 | o-ran.org | Thanks to PlantUML!
end footer

hide stereotype
skinparam backgroundColor #fefefe

skinparam backgroundColor #fefefe
'skinparam handwritten true
skinparam roundcorner 15

skinparam class {
  BorderColor #444444
  BackgroundColor #ffffdd
  FontColor #444444
}

skinparam component {
  BorderColor #444444
  BackgroundColor #ffffdd
  BackgroundColor<<control>> #ffff00
  BackgroundColor<<compute>> #eeeeee
  FontColor #444444
}

skinparam database {
  BorderColor #444444
  BackgroundColor #ffffdd
  FontColor #444444
}

skinparam note {
  BorderColor #444444
  BackgroundColor #ffffdd
  FontColor #444444
}

skinparam sequence {
  MessageAlign left
  ArrowThickness 2
  ArrowColor #2277dd
  ArrowFontColor #444444
  ActorBorderColor #444444
  LifeLineBorderColor #444444
  LifeLineBackgroundColor #eeeeee
 
  BoxBorderColor #444444
    
  GroupBorderColor #444444
  GroupBackgroundColor #eeeeee
  
  ParticipantBorderColor #444444
  ParticipantBackgroundColor #ffffdd
  ParticipantFontColor #444444
    
  ActorBackgroundColor #ffffdd
  'ActorFontColor DeepSkyBlue
  'ActorFontSize 17
  'ActorFontName Aapex
}
@enduml


DMZ

DMZ (demilitarized zone) contains and exposes external services to the internet (IPv4 only).

SMO

The primary network to exchange data between the physical nodes and virtual machines related to the SMO components

OAM

The primary network for interactions between SMO-OAM components and network functions.