+--rw simulator-config
| +--rw simulated-devices? uint32
| +--rw mounted-devices? uint32
+ | +--rw ssh-connections? uint32
+ | +--rw tls-connections? uint32
| +--rw notification-config
- | | +--rw fault-notification-delay-period? uint32
+ | | +--rw fault-notification-delay-period* uint32
| | +--rw ves-heartbeat-period? uint32
| | +--rw is-netconf-available? boolean
| | +--rw is-ves-available? boolean
| +--ro base-netconf-port? uint32
| +--ro cpu-usage? percent
| +--ro mem-usage? uint32
+ +--ro notification-count
+ | +--ro total-ves-notifications
+ | | +--ro normal? uint32
+ | | +--ro warning? uint32
+ | | +--ro minor? uint32
+ | | +--ro major? uint32
+ | | +--ro critical? uint32
+ | +--ro total-netconf-notifications
+ | +--ro normal? uint32
+ | +--ro warning? uint32
+ | +--ro minor? uint32
+ | +--ro major? uint32
+ | +--ro critical? uint32
+--ro simulated-devices-list* [uuid]
- +--ro uuid string
- +--ro device-ip? string
- +--ro device-port* uint32
- +--ro is-mounted? boolean
- +--ro operational-state? operational-state-type
+ +--ro uuid string
+ +--ro device-ip? string
+ +--ro device-port* uint32
+ +--ro is-mounted? boolean
+ +--ro operational-state? operational-state-type
+ +--ro notification-count
+ +--ro ves-notifications
+ | +--ro normal? uint32
+ | +--ro warning? uint32
+ | +--ro minor? uint32
+ | +--ro major? uint32
+ | +--ro critical? uint32
+ +--ro netconf-notifications
+ +--ro normal? uint32
+ +--ro warning? uint32
+ +--ro minor? uint32
+ +--ro major? uint32
+ +--ro critical? uint32
rpcs:
+---x restart-simulation
##### Configuration
* **simulated-devices** - represents the number of simulated devices. The default value is 0, meaning that when the NTS is started, there are no simulated devices. When this value is increased to **n**, the NTS Manager starts docker containers in order to reach **n** simulated devices. If the value is decreased to **k**, the NTS Manager will remove docker containers, until the number of simulated devices reaches **k**;
-* **mounted-devices** - represents the number of devices to be mounted to an ODL based SDN Controller. The same phylosophy as in the case of the previous leaf applies. If this number is increased, the number of ODL mountpoints increases. Else, the simulated devices are being unmounted from ODL. The number of mounted devices cannot exceed the number of simulated devices. The details about the ODL controller where to mount/unmount are given by the **controller-details** container; **Please note that this cannot be set to a value > 0 if the *ves-registration* leaf is set to 'True'**; For each simulated device, 10 NETCONF endpoints will be mounted (7 SSH + 3 TLS). See **NETCONF Endpoints** section for more details.
+* **mounted-devices** - represents the number of devices to be mounted to an ODL based SDN Controller. The same phylosophy as in the case of the previous leaf applies. If this number is increased, the number of ODL mountpoints increases. Else, the simulated devices are being unmounted from ODL. The number of mounted devices cannot exceed the number of simulated devices. The details about the ODL controller where to mount/unmount are given by the **controller-details** container; **Please note that this cannot be set to a value > 0 if the *ves-registration* leaf is set to 'True'**; For each simulated device, a number of NETCONF endpoints will be mounted, according to the **ssh-connections** and **tls-connections** leafs. See **NETCONF Endpoints** section for more details;
+* **ssh-connections** - represents the number of SSH endpoints to be exposed by each of the simulated devices. **Please note that the total number of SSH and TLS connections cannot exceed 100.** The default value is 1. **The value can only be changed when simulated-devices is 0**.
+* **tls-connectioons** - represents the number of TLS endpoints to be exposed by each of the simulated devices. **Please note that the total number of SSH and TLS connections cannot exceed 100.** The default value is 0. **The value can only be changed when simulated-devices is 0**.
* **notification-config** - this container groups the configuration about fault notification generation of each simulated device;
-* **fault-notification-delay-period** - the amount of seconds between two generated fault notifications. For example, if this has a value of *10*, each simulated device will generate a **random** fault notification every *10* seconds;
+* **fault-notification-delay-period** - the amount of seconds between two generated fault notifications. For example, if this has a value of *10*, each simulated device will generate a **random** fault notification every *10* seconds; **when this is set to 0, it will reset the notification counters for the VES and NETCONF notifications, which are exposed in the simulator-status**;
* **ves-heartbeat-period** - the amount of seconds between VES heartbeat messages that can be generated by each simulated device. The details about the VES connection endpoint are given in the **ves-endpoint-details** container;
* **is-netconf-available** - if set to 'True', NETCONF notifications will be sent when a random fault notification is generated, The NETCONF notification that is being sent is currently *o-ran-fm:alarm-notif*; if set to 'False', NETCONF notifications are not being sent out;
* **is-ves-available** - if set to 'True', VES *faultNotification* messages will be sent when a random fault notification is generated; if set to 'False', VES *faultNotification* messages are not generated;
* **ves-endpoint-username** - the username to be used when authenticating to the VES endpoint;
* **ves-endpoint-password** - the password to be used when authenticating to the VES endpoint;
* **ves-endpoint-certificate** - the certificate to be used when authenticating to the VES endpoint;
-* **ves-registration** - if this is set to 'True' **when simulated devices are starting**, each simulated device will send out *pnfRegistration* VES messages to the configured VES endpoint; if this is set to 'False', *pnfRegistration* VES messages will not be sent out. **Please note that this cannot be set to 'True' is simulated devices are already mounted to ODL based SDN controller (mounted-devices leaf > 0)**; For each simulated device, 10 pnfRegistration VES messages will be sent out (7 SSH + 3 TLS). See **NETCONF Endpoints** section for more details.
+* **ves-registration** - if this is set to 'True' **when simulated devices are starting**, each simulated device will send out *pnfRegistration* VES messages to the configured VES endpoint; if this is set to 'False', *pnfRegistration* VES messages will not be sent out. **Please note that this cannot be set to 'True' is simulated devices are already mounted to ODL based SDN controller (mounted-devices leaf > 0)**; For each simulated device, **ssh-connections + tls-connections** pnfRegistration VES messages will be sent out. See **NETCONF Endpoints** section for more details.
##### Status
* **base-netconf-port** - the port that was used as a base when craeting simulated devices;
* **cpu-usage** - the percentage of the CPU used currently by the simulation framework;
* **mem-usage** - the amount of RAM used (in MB) currently by the simulation framework;
+* **notification-count** - this container groups the details about the total number of notifications that were generated by the simulated devices;
+* **total-ves-notifications** - this container groups the details about the total number of VES notifications that were generated by the simulated devices, grouped by severity;
+* **total-netcnof-notifications** - this container groups the details about the total number of NETCONF notifications that were generated by the simulated devices - grouped by severity;
* **simulated-devices-list** - this list contains the details about each simulated devices that is currently running;
* **uuid** - the Universally Unique ID of the simulated device;
* **device-ip** - the IP address of the simulated device;
* **device-port** - the port of the simulated device, where the NETCONF connection is exposed;
* **is-mounted** - boolean to show whether the device is currently mounted to an ODL based SDN controller;
-* **operational-state** - the operational state of the current simulated device; it can be either *not-specified*, *created*, *running* or *exited*.
+* **operational-state** - the operational state of the current simulated device; it can be either *not-specified*, *created*, *running* or *exited*;
+* **notification-count** - this container groups the details about the number of notifications that were generated by this particular simulated device;
+* **ves-notifications** - this container groups the details about the number of VES notifications that were generated by this simulated device, grouped by severity;
+* **netconf-notifications** - this container groups the details about the number of NETCONF notifications that were generated by this simulated device - grouped by severity.
##### RPCs
#### NETCONF Endpoints
-Each simulated device exposes **10 NETCONF endpoints**, on 10 consecutive ports. The first simulated device uses the 10 ports starting from the **NETCONF_BASE** environment variable used when starting the NTST Manager, while the nextt one uses the next 10 ports and so on and so forth. E.g. if the **NETCONF_BASE=50000** the first simulated device will expose ports from *50000* to *50009*, the second simulated device will expose ports from *50010* to *50019* etc.
+Each simulated device exposes a number of NETCONF endpoints which represented by the sum of the **ssh-connections** and **tls-connections** leafs, on consecutive ports. The first simulated device uses the ports starting from the **NETCONF_BASE** environment variable used when starting the NTS Manager, while the next one uses the next ports and so on and so forth. E.g. if the **NETCONF_BASE=50000** and **ssh-connections=5** and **tls-connections=3**, the first simulated device will expose ports from *50000* to *50007*, the second simulated device will expose ports from *5008* to *50015* etc.
-The first 7 connections exposed by a simulated device are **SSH** based. A NETCONF client can connect to the exposed endpoint using one of the SSH ports (e.g. 50000 to 50006) and the **username/password**: *netconf/netconf*.
+The first **ssh-connections** ports exposed by a simulated device are **SSH** based. A NETCONF client can connect to the exposed endpoint using one of the SSH ports (e.g. 50000 to 50007, considering the previous example) and the **username/password**: *netconf/netconf*.
-The last 3 connections exposed by a simulated device are **TLS** based. A NETCONF client can connect to the exposed endpoint using one of the TLS ports (e.g. 50007 to 50009), using a valid certificate and the **username**: *netconf*.
+The last **tls-connections** ports exposed by a simulated device are **TLS** based. A NETCONF client can connect to the exposed endpoint using one of the TLS ports (e.g. 50006 to 50008, considering the previous example), using a valid certificate and the **username**: *netconf*.
## Usage
### Building the images
-The `docker-build-manager.sh` script can be used to built the docker image associated with the NTS Manager. This will create a docker image named *ntsim_manager*, which will be used to start the simulation framework. Inside the docker image, port 830 will wait for connections for the NETCONF/YANG management interface.
+The `docker-build-nts-manager.sh` script can be used to built the docker image associated with the NTS Manager. This will create a docker image named *ntsim_manager_light*, which will be used to start the simulation framework. Inside the docker image, port 830 will wait for connections for the NETCONF/YANG management interface.
-The `docker-build-model.sh` script can be used to build the docker image associated with a simulated device. Currently, this will create a docker image named *ntsim_oran*, which will be used by the manager to start the docker containers for each simulated device.
+The `docker-build-onf-core-model-1-2.sh` script can be used to build the docker image associated with a simulated device, exposing the ONF CoreModel version 1.2.
+
+The `docker-build-onf-core-model-1-4.sh` script can be used to build the docker image associated with a simulated device, exposing the ONF CoreModel version 1.4.
+
+The `docker-build-openroadm.sh` script can be used to build the docker image associated with a simulated device, exposing the OpenROADM models.
+
+The `docker-build-o-ran-device.sh` script can be used to build the docker image associated with a simulated device, exposing the O-RAN models.
+
+The `docker-build-o-ran-sc-o-ran-ru.sh` script can be used to build the docker image associated with a simulated device, exposing the O-RAN-SC models.
+
+The `docker-build-x-ran-device.sh*` script can be used to build the docker image associated with a simulated device, exposing the X-RAN models.
### Starting the NTS Manager
image: "ntsim_manager:latest"
container_name: NTS_Manager
ports:
- - "172.17.0.1:8300:830"
+ - "8300:830"
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
- - "/path/to/simulator/folder/ntsimulator/scripts:/opt/dev/scripts"
+ - "/var/tmp/NTS_Manager:/opt/dev/scripts"
- "/usr/bin/docker:/usr/bin/docker"
labels:
"NTS-manager": ""
NETCONF_BASE: 50000
DOCKER_ENGINE_VERSION: "1.40"
MODELS_IMAGE: "ntsim_oran"
+ VesHeartbeatPeriod: 0
+ IsVesAvailable: "true"
+ IsNetconfAvailable: "true"
+ VesRegistration: "false"
+ VesEndpointPort: 8080
+ VesEndpointIp: "172.17.0.1"
+ SshConnections: 1
+ TlsConnections: 0
+ K8S_DEPLOYMENT: "false"
```
* Port mapping:
- * `"172.17.0.1:8300:830"` - this maps the *830* port from inside the docker container of the NTS Manager to the port *8300* from the host, and binds it to the docker IP address *172.17.0.1*:
+ * `"8300:830"` - this maps the *830* port from inside the docker container of the NTS Manager to the port *8300* from the host, and binds it to any IP address on the host:
* Volumes - these map 3 important things:
* the docker socket from the host is mapped inside the docker container:
`/var/run/docker.sock:/var/run/docker.sock` - **please do not modify the path inside the container!**;
- * the **scripts** folder from the cloned repository needs to be mapped inside the container:
- `/path/to/simulator/folder/ntsimulator/scripts:/opt/dev/scripts` - **please do not modify the path inside the container!**;
+ * any folder from the host can be mapped to inside the docker container into othe **/opt/dev/scripts** folder:
+ `/var/tmp/NTS_Manager:/opt/dev/scripts` - **please do not modify the path inside the container!**;
* the path to the docker executable needs to be mapped inside the container:
`/usr/bin/docker:/usr/bin/docker` - **please do not modify the path inside the container!**;
* **NETCONF_BASE** - this is the starting port used to expose NETCONF endpoints. Starting from this, each device will use 10 consecutive ports for its endpoints;
* **DOCKER_ENGINE_VERSION** - this is the version of the *docker engine* installed currently on the host. This can be verified using `docker version` command in the host, and looking to the `API version: #.##` variable from the Server details.
* **MODELS_IMAGE** - this represents the name of the docker image that represents the simulated device. The NTS Manager will start containers using this image, when starting simulated devices.
+ * **VesHeartbeatPeriod** - this can change the default value of the **ves-heartbeat-period** leaf used by the NTS Manager.
+ * **IsVesAvailable** - this can change the default value of the **is-ves-available** leaf used by the NTS Manager.
+ * **IsNetconfAvailable** - this can change the default value of the **is-netconf-available** leaf used by the NTS Manager.
+ * **VesRegistration** - this can change the default value of the **ves-registration** leaf used by the NTS Manager.
+ * **VesEndpointPort** - this can change the default value of the **ves-endpoint-port** leaf used by the NTS Manager.
+ * **VesEndpointIp** - this can change the default value of the **ves-endpoint-ip** leaf used by the NTS Manager.
+ * **SshConnections** - this can change the default value of the **ssh-connections** leaf used by the NTS Manager.
+ * **TlsConnections** - this can change the default value of the **tls-connections** leaf used by the NTS Manager.
+ * **K8S_DEPLOYMENT** - this value can be set to `true` when the user wants to the NTS Framework in a Kubernetes deployment. The default is `false`.
After modifying the `docker-compose.yml` file with values specific to your host, the NTS Manager can be started by running the command `docker-compose up` from the **scripts** folder.
Example of `docker ps` command result, after the NTS Manager was started:
```
-7ff723b7f794 ntsim_manager:latest "sh -c '/usr/bin/sup…" 5 days ago Up 5 days 172.17.0.1:8300->830/tcp NTS_Manager
+7ff723b7f794 ntsim_manager:latest "sh -c '/usr/bin/sup…" 5 days ago Up 5 days 0.0.0.0:8300->830/tcp NTS_Manager
```
-### Using the NTST Manager
+### Using the NTS Manager
When the NTS Manager is started, its default configuration looks like this:
<simulator-config xmlns="urn:onf:params:xml:ns:yang:network-topology-simulator">
<simulated-devices>0</simulated-devices>
<mounted-devices>0</mounted-devices>
+ <ssh-connections>1</ssh-connections>
+ <tls-connections>0</tls-connections>
<notification-config>
<fault-notification-delay-period>0</fault-notification-delay-period>
<ves-heartbeat-period>0</ves-heartbeat-period>
### Starting a simulated device
-Example of starting **one** simulated device:
+Example RPC for starting **one** simulated device:
+
+```xml
+<?xml version="1.0" encoding="utf-8"?>
+<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="">
+ <edit-config>
+ <target>
+ <running/>
+ </target>
+ <config>
+ <simulator-config xmlns="urn:onf:params:xml:ns:yang:network-topology-simulator">
+ <simulated-devices>1</simulated-devices>
+ <!--We need to delete the ssh-connections and tls-connections leafs when configuring simulated-devices > 0 -->
+ <ssh-connections xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0" xc:operation="delete"/>
+ <tls-connections xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0" xc:operation="delete"/>
+ </simulator-config>
+ </config>
+ </edit-config>
+</rpc>
+```
+
If the leaf `<simulated-devices>1</simulated-devices>` will be set to a value of **1**, the NTS Manager will start a new docker container. We can verify that this was successfull by running the `docker ps` command. The results will look like this:
c18eb7a362f5 ntsim_oran "sh -c '/usr/bin/sup…" 4 days ago Up 4 days 172.17.0.1:50000->830/tcp, 172.17.0.1:50001->831/tcp, 172.17.0.1:50002->832/tcp, 172.17.0.1:50003->833/tcp, 172.17.0.1:50004->834/tcp, 172.17.0.1:50005->835/tcp, 172.17.0.1:50006->836/tcp, 172.17.0.1:50007->837/tcp, 172.17.0.1:50008->838/tcp, 172.17.0.1:50009->839/tcp reverent_bhabha
```
-We can see that the simulated device has 10 NETCONF Endpoints listening for connections. The first 7 (50000 to 50006) are SSH connections, while the last 3 (50007 to 50009) are TLS connections.
-
## Troubleshooting
Example of a result of such a command:
```
-ntsim_oran latest 57b065de4458 4 days ago 785MB
+ntsim_oran_light latest 57b065de4458 4 days ago 186MB
```
-This means that `MODELS_IMAGE: "ntsim_oran:latest"` can be used as an environment variable when starting the NTS Manager.
\ No newline at end of file
+This means that `MODELS_IMAGE: "ntsim_oran_light:latest"` can be used as an environment variable when starting the NTS Manager.
\ No newline at end of file
Code Review / sim / o1-interface.git / blobdiff