The NTS framework is based on several open-source projects
- `cJSON <https://github.com/DaveGamble/cJSON>`_
-- `libcurl <https://curl.haxx.se>`_
+- `libcurl <https://curl.se>`_
- `libyang <https://github.com/CESNET/libyang>`_
- `sysrepo <https://github.com/sysrepo/sysrepo>`_
- `libnetconf2 <https://github.com/CESNET/libnetconf2>`_
| +--rw controller-protocol? enumeration
| +--rw controller-ip? inet:ip-address
| +--rw controller-port? inet:port-number
+ | +--rw controller-netconf-call-home-ip? inet:ip-address
| +--rw controller-netconf-call-home-port? inet:port-number
| +--rw controller-username? string
| +--rw controller-password? string
- **network-functions** - represents the simulation data, which will be best described below
- **sdn-controller** - this container groups the configuration related to the ODL based SDN controller that the simulated devices can connect to:
-
+
- **controller-protocol** - SDN controller protocol (http/https)
- **controller-ip** - the IP address of the ODL based SDN controller where the simulated devices can be mounted. Both IPv4 and IPv6 are supported
- **controller-port** - the port of the ODL based SDN controller
+ - **controller-netconf-call-home-ip** - the IP address of the ODL based SDN controller where the simulated devices can Call Home via the NETCONF Call Home feature.
- **controller-netconf-call-home-port** - the NETCONF Call Home port of the ODL based SDN controller
- **controller-username** - the username to be used when connecting to the ODL based SDN controller
- **controller-password** - the password to be used when connecting to the ODL based SDN controller
+ *cert-only* - certificate only authentication in this case the certificate to be used for the communication must be configured
+ *basic-auth* - classic username/password authentication in this case both the username and password need to be configured
+ *cert-basic-auth* - authentication that uses both username/password and a certificate all three values need to be configured in this case
- +
+ +
- **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
- **started-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 in a LIFO manner, 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 started devices. The details about the ODL controller where to mount/unmount are given by the **sdn-controller** container
- **mount-point-addressing-method** - addressing method of the mount point. Possible values are:
-
+
+ *docker-mapping* - [default value] future started simulated devices will be mapped on the Docker container
+ *host-mapping* - future started simulated devices will me mapped on the host's IP address and port based on *base-port*
- **docker-instance-name** - the prefix for future simulated devices (to this name a dash and an increasing number is added)
There are 2 defined **notifications**:
- **instance-changed** notification: is called by the manager whenever a change is done to any of the network functions. This contains data about the change:
-
+
- **change-status**: is a string which has the following structure: operation STATUS - info. operation can be *start*, *stop*, *mount*, *unmount*, *config* and *reconfig*; STATUS can be SUCCESS or FAILED; info can be present or not, depending on what further information is available about the change
- **function-type**: the function-type for the instance
- **name**: name of the instance that is changed
- **networking**: when starting and configuring an instance, this container has all the necessary networking data, such as IP and ports
-
+
- **operation-status-changed** notification is called by the manager at the end of an operation:
- **status** returns the status of the operation: SUCCESS/FAILED. This status can also be statically read from the operational datastore under *nts-manager:simulation/last-operation-status*
+--rw sdn-controller
| +--rw controller-ip? inet:ip-address
| +--rw controller-port? inet:port-number
+ | +--rw controller-netconf-call-home-ip? inet:ip-address
| +--rw controller-netconf-call-home-port? inet:port-number
| +--rw controller-username? string
| +--rw controller-password? string
- **ves-file-ready** - enables VES file ready, and stats a FTP and a SFTP server on the network function
- **ves-heartbeat** - enabled VES heartbeat feature
- **ves-pnf-registration*** - enables VES PNF registration
+ - **ves-o1-pnf-registration*** - enables O1 VES PNF registration (stndDefined)
- **manual-notification-generation** - enables the manual notification generation feature
- **netconf-call-home*** - enables NETCONF's Call Home feature
- **web-cut-through** - enables web cut through, adding the info to the ietf-system module
- **invoke-notification** - this RPC is used for forcing a simulated device to send a NETCONF notification, as defined by the user:
- The **input** needed by the RPC:
-
+
- **notification-format** - can be either *json* or *xml*
- **notification-object** - this is a string containing the notification object that we are trying to send from the simulated device, in JSON format. **Please note that the user has the responsibility to ensure that the JSON object is valid, according to the definition of the notification in the YANG module.** There is no possibility to see what was wrong when trying to send an incorrect notification. The RPC will only respond with an "ERROR" status in that case, without further information. E.g. of a JSON containing a notification object of type ***otdr-scan-result*** defined in the ***org-openroadm-device*** YANG module: ***{"org-openroadm-device:otdr-scan-result":{"status":"Successful","status-message":"Scan result was successful","result-file":"/home/result-file.txt"}}***. **Please note that the notification object contains also the name of the YANG model defning it, as a namespace, as seen in the example.**
- The **output** returned by the RPC:
-
+
- **status** - if the notification was send successfully by the simulated device, the RPC will return a **SUCCESS** value. Else, the RPC will return a **ERROR** value.
- **invoke-ves-pm-file-ready** - as name impiles, it invokes a file ready VES request, with a specified *file-location*
Other than this, the network-function will operate just as it would when started by the manager and it can be controller through the **nts-network-function.yang** interface.
+The default mount point addressing method is "docker-mapping". However this behaviour can be changed by setting the **NTS_NF_MOUNT_POINT_ADDRESSING_METHOD** enviroment variable to "host-mapping". When "host-mapping" is chosen, all the host ports must be fowareded from Docker by the user when running the network function, and **NTS_HOST_IP** and **NTS_HOST_xxxx_PORT** enviroment variables should be set for the network function to know how to perform its tasks.
+
Datastore random population
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
],
"debug-max-string-size" : 50, //max size of string. if not set, default is 255
-
+
"default-list-instances": 1, //default number of instances a list or a leaflist should be populated with
"custom-list-instances" : [ //custom number of list instances. instance is schema name, and should reflect a list or a leaflist
{"/ietf-interfaces:interfaces/interface": 2}, //2 instances of this. if 0, list will be excluded from populating
"path/to/data.json",
"path/to/data.xml"
],
-
+
"pre-generated-running-data": [ //path with files containing NETCONF data, either JSON or XML
"path/to/data.json",
"path/to/data.xml"
- --help - shows the help (also described here)
- --version - describes ntsng version and build time
- **main modes**:
-
+
- --container-init - is automatically used by Docker when building the images to install modules and enable features. Described in the next chapter. **Do not run manually**
- --supervisor - runs in supervisor mode (configuration is done via config.json)
- --manager - runs in manager mode
- --verbose - set the verbose level. can range from 0 (errors-only) to 2 (verbose), default is 1 (info)
- --workspace - set the current working workspace. the workspace **MUST** be writeable and should contain *config/config.json* file, otherwise a blank json file will be created
- tools:
-
+
- --ls - list all modules in the datastore with their attributes
- --schema - list the schema of an xpath given as parameter
- **NTS_BUILD_VERSION** - defines build version, set by Dockerfile
- **NTS_BUILD_DATE** - defines build date, set by Dockerfile
- **NTS_NF_STANDALONE_START_FEATURES** - when value is not blank, it allows the network function to run in standalone mode; see "Network function standalone mode" sub-chapter for this
+- **NTS_NF_MOUNT_POINT_ADDRESSING_METHOD** - either "docker-mapping" or "host-mapping"; available only when running in network function STANDALONE MODE
- **DOCKER_ENGINE_VERSION** - Docker engine version, defaults to 1.40 if not set
- **HOSTNAME** - Container hostname
- **SDN_CONTROLLER_PROTOCOL** - protocol used for communication with the SDN controller (http or https, defaults to https)
- **SDN_CONTROLLER_IP** - SDN controller IP address
- **SDN_CONTROLLER_PORT** - SDN controller port
+- **SDN_CONTROLLER_CALLHOME_IP** - SDN controller IP address for NETCONF call-home
- **SDN_CONTROLLER_CALLHOME_PORT** - SDN controller port for NETCONF call-home
- **SDN_CONTROLLER_USERNAME** - SDN controller username
- **SDN_CONTROLLER_PASSWORD** - SDN controller password
- **NTS_HOST_IP**: an IP address from the host, which should be used by systems outside the local machine to address the simulators;
- **NTS_HOST_BASE_PORT**: the port from where the allocation for the simulated network functions should start, if not specified otherwise sepparately (see below); any port not defined will automatically be assigned to *BASE_PORT*; **NOTE** that in order for a port to be eligible, it must be greater than or equal to **1000**:
-
+
- **NTS_HOST_NETCONF_SSH_BASE_PORT**
- **NTS_HOST_NETCONF_TLS_BASE_PORT**
- **NTS_HOST_TRANSFER_FTP_BASE_PORT**
-----------------------
One could start 1 instance of a simulated O-RU-FH and 1 instance of a simulated O-DU by running the `nts-start.sh` script. Pre-configured values can be set in the `.env` file.
+
+Building O-DU O1 Simulator image with 3GPP YANG models
+------------------------------------------------------
+
+Because of the license of the 3GPP YANG models, we cannot use the same approach as for the other simulated NFs (hosting docker images in LF Nexus repositories) for the simulated O-DU containing 3GPP YANG models. In order to provide such a simulator nevertheless, we provide here the recipe to build such an image locally, thus not breaking any license.
+
+Building such an image is pretty straightforward:
+
+1. run the `nts_build_o_du_rel_18.sh` bash script from `ntsimulator` folder. It will download the necessary 3GPP YANG models and then produce a docker image with the name `nts-ng-o-ran-du-rel-18` and the version tag defined in the `.env` file, under the `NTS_BUILD_VERSION` environment variable.
+
+O-RU feature: monitoring NETCONF connectivity
+---------------------------------------------
+
+O-RAN.WG4.MP.0-R003-v11.00 defines, in chapter 6.7, a mechanism for monitoring the NETCONF connectivity to the O-RU.
+
+The simulated O-RU implements such a functionality: it listens for supervision-watchdog-reset RPC defined in the o-ran-supervision YANG model and reacts to it, replying with the time when the next supervision-notification will be sent. After the supervision-notification-interval has passed (default 60 seconds), the supervision-notification defined in the o-ran-supervision YANG model will be sent. The O-RU simulator waits then for another guard-time-overhead seconds (default 10 seconds) for receiving a new supervision-watchdog-reset RPC. If it is received, the mechanism starts again (either with the default values, or with the values that come inside the RPC). If not, a message is logged (`Failed to receive watchdog reset, terminating supervision timer for o-ran-supervision..`) and the mechanism stops sending any notifications.
Code Review / sim / o1-interface.git / blobdiff