docs/overview.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. SPDX-License-Identifier: CC-BY-4.0
   3 .. Copyright (C) 2019 highstreet technologies GmbH and others
   4
   5
   6 sim/o1-interface Overview
   7 ==========================
   8
   9 Network Topology Simulator (NTS) | next generation
  10 ==================================================
  11
  12 The Network Topology Simulator is a framework that allows simulating devices that expose a management interface through a NETCONF/YANG interface.
  13
  14 # Description
  15 =============
  16
  17 ## Overview
  18 ===========
  19
  20 The NETCONF/YANG management interface is simulated, and any YANG models can be loaded by the framework to be exposed. Random data is generated based on the specific models, such that each simulated device presents different data on its management interface.
  21
  22 The NTS framework is based on several open-source projects:
  23
  24 * `cJSON <https://github.com/DaveGamble/cJSON>`_
  25
  26 * `libcurl <https://curl.haxx.se>`_
  27
  28 * `libyang <https://github.com/CESNET/libyang>`_
  29
  30 * `sysrepo <https://github.com/sysrepo/sysrepo>`_
  31
  32 * `libnetconf2 <https://github.com/CESNET/libnetconf2>`_
  33
  34 * `Netopeer2 <https://github.com/CESNET/Netopeer2>`_
  35
  36 The NTS Manager can be used to specify the simulation details and to manage the simulation environment at runtime.
  37
  38 Each simulated device is represented as a docker container, where the NETCONF Server is running. The creation and deletion of docker containers associated with simulated devices is handled by the NTS Manager. The NTS Manager is also running as a docker container and exposes a NETCONF/YANG interface to control the simulation.
  39
  40 ## NTS Manager
  41 ==============
  42
  43 The purpose of the NTS Manager is to ease the utilization of the NTS framework. It enables the user to interact with the simulation framework through a NETCONF/YANG interface. The user has the ability to modify the simulation parameters at runtime and to see the status of the current state of the NTS. The NETCONF/YANG interface will be detailed below.
  44
  45
  46 module: nts-manager
  47
  48   +--rw simulation
  49
  50          +\-\-rw network\-functions
  51
  52          |  +\-\-rw network\-function\* [function\-type]
  53
  54          |     +\-\-rw function\-type                    identityref
  55
  56          |     +\-\-rw started\-instances                uint16
  57
  58          |     +\-\-rw mounted\-instances                uint16
  59
  60          |     +\-\-rw mount\-point\-addressing\-method?   enumeration
  61
  62          |     +\-\-rw docker\-instance\-name             string
  63
  64          |     +\-\-rw docker\-version\-tag               string
  65
  66          |     +\-\-rw docker\-repository                string
  67
  68          |     +\-\-rw fault\-generation
  69
  70          |     |  +\-\-rw fault\-delay\-list\* [index]
  71
  72          |     |  |  +\-\-rw index           uint16
  73
  74          |     |  |  +\-\-rw delay\-period?   uint16
  75
  76          |     |  +\-\-ro fault\-count {faults\-status}?
  77
  78          |     |     +\-\-ro normal?     uint32
  79
  80          |     |     +\-\-ro warning?    uint32
  81
  82          |     |     +\-\-ro minor?      uint32
  83
  84          |     |     +\-\-ro major?      uint32
  85
  86          |     |     +\-\-ro critical?   uint32
  87
  88          |     +\-\-rw netconf
  89
  90          |     |  +\-\-rw faults\-enabled?   boolean
  91
  92          |     |  +\-\-rw call\-home?        boolean
  93
  94          |     +\-\-rw ves
  95
  96          |     |  +\-\-rw faults\-enabled?     boolean
  97
  98          |     |  +\-\-rw pnf\-registration?   boolean
  99
 100          |     |  +\-\-rw heartbeat\-period?   uint16
 101
 102          |     +\-\-ro instances
 103
 104          |        +\-\-ro instance\* [name]
 105
 106          |           +\-\-ro mount\-point\-addressing\-method?   enumeration
 107
 108          |           +\-\-ro name                             string
 109
 110          |           +\-\-ro networking
 111
 112          |              +\-\-ro docker\-ip?     inet:ip\-address
 113
 114          |              +\-\-ro docker\-port\*   inet:port\-number
 115
 116          |              +\-\-ro host\-ip?       inet:ip\-address
 117
 118          |              +\-\-ro host\-port\*     inet:port\-number
 119
 120          +\-\-rw sdn\-controller
 121
 122          |  +\-\-rw controller\-ip?                       inet:ip\-address
 123
 124          |  +\-\-rw controller\-port?                     inet:port\-number
 125
 126          |  +\-\-rw controller\-netconf\-call\-home\-port?   inet:port\-number
 127
 128          |  +\-\-rw controller\-username?                 string
 129
 130          |  +\-\-rw controller\-password?                 string
 131
 132          +\-\-rw ves\-endpoint
 133
 134          |  +\-\-rw ves\-endpoint\-protocol?      enumeration
 135
 136          |  +\-\-rw ves\-endpoint\-ip?            inet:ip\-address
 137
 138          |  +\-\-rw ves\-endpoint\-port?          inet:port\-number
 139
 140          |  +\-\-rw ves\-endpoint\-auth\-method?   authentication\-method\-type
 141
 142          |  +\-\-rw ves\-endpoint\-username?      string
 143
 144          |  +\-\-rw ves\-endpoint\-password?      string
 145
 146          |  +\-\-rw ves\-endpoint\-certificate?   string
 147
 148          +\-\-ro base\-port?           inet:port\-number
 149
 150          +\-\-ro ssh\-connections?     uint8
 151
 152          +\-\-ro tls\-connections?     uint8
 153
 154          +\-\-ro cpu\-usage?           percent
 155
 156          +\-\-ro mem\-usage?           uint32
 157
 158
 159 ### Detailed information about the YANG attributes
 160 ==================================================
 161
 162 Under **simulation** there are 3 configuration containers and a couple of statistics leafs:
 163
 164 * **network-functions** - represents the simulation data, which will be best described below
 165
 166 * **sdn-controller** - this container groups the configuration related to the ODL based SDN controller that the simulated devices can connect to
 167
 168         \* \*\*controller\-ip\*\* \- the IP address of the ODL based SDN controller where the simulated devices can be mounted. Both IPv4 and IPv6 are supported
 169
 170         \* \*\*controller\-port\*\* \- the port of the ODL based SDN controller
 171
 172         \* \*\*controller\-netconf\-call\-home\-port\*\* \- the NETCONF Call Home port of the ODL based SDN controller
 173
 174         \* \*\*controller\-username\*\* \- the username to be used when connecting to the ODL based SDN controller
 175
 176         \* \*\*controller\-password\*\* \- the password to be used when connecting to the ODL based SDN controller
 177
 178 * **ves-endpoint** - this container groups the configuration related to the VES endpoint where the VES messages are targeted
 179
 180         \* \*\*ves\-endpoint\-protocol\*\* \- the protocol of the VES endpoint where VES messages are targeted
 181
 182         \* \*\*ves\-endpoint\-ip\*\* \- the IP address of the VES endpoint where VES messages are targeted
 183
 184         \* \*\*ves\-endpoint\-port\*\* \- the port address of the VES endpoint where VES messages are targeted
 185
 186         \* \*\*ves\-endpoint\-auth\-method\*\* \- the authentication method to be used when sending the VES message to the VES endpoint. Possible values are:
 187
 188                 + \*no\-auth\* \- no authentication
 189
 190                 + \*cert\-only\* \- certificate only authentication in this case the certificate to be used for the communication must be configured
 191
 192                 + \*basic\-auth\* \- classic username/password authentication in this case both the username and password need to be configured
 193
 194                 + \*cert\-basic\-auth\* \- authentication that uses both username/password and a certificate all three values need to be configured in this case
 195
 196         \* \*\*ves\-endpoint\-username\*\* \- the username to be used when authenticating to the VES endpoint
 197
 198         \* \*\*ves\-endpoint\-password\*\* \- the password to be used when authenticating to the VES endpoint
 199
 200         \* \*\*ves\-endpoint\-certificate\*\* \- the certificate to be used when authenticating to the VES endpoint
 201
 202 * base-port - status node indicating the start port for mapping the simulated network functions; ports are assigned in an increasing order starting from this base port
 203
 204 * ssh-connections - status node indicating the number of SSH Endpoints each network function instance exposes
 205
 206 * tls-connections - status node indicating the number of TLS Endpoints each network function instance exposes
 207
 208 * cpu-usage - status node indicating the **total** CPU usage of the simulation
 209
 210 * mem-usage - status node indicating the **total** memory usage of the simulation
 211
 212 Under the **network-functions** there is the **network-function** list. This list is automatically populated by the NTS Manager at start time with the available network functions. No changes at the actual list are allowed (adding or removing elements), only the changes of the properties of the elements have effect. The structure of an element of this list is described below:
 213
 214 * **function-type** - the function type
 215
 216 * **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**
 217
 218 * **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
 219
 220 * **mount-point-addressing-method** - addressing method of the mount point. Possible values are:
 221
 222         + \*docker\-mapping\* \- [default value] future started simulated devices will be mapped on the Docker container
 223
 224         + \*host\-mapping\* \- future started simulated devices will me mapped on the host's IP address and port based on \*base\-port\*
 225
 226 * **docker-instance-name** - the prefix for future simulated devices (to this name a dash and an increasing number is added)
 227
 228 * **docker-version-tag** - a specific version tag for the Docker container to be ran. if empty, the latest version is ran
 229
 230 * **docker-repository** - the prefix for containing the Docker repository information. if local repository is used, value can be either blank or *local*
 231
 232 * **fault-generation** - container which groups the fault generation features, explained later
 233
 234 * **netconf** - container with settings for enabling or disabling netconf features
 235
 236         \* \*\*faults\-enabled\*\* \- enable or disable faults over netconf
 237
 238         \* \*\*call\-home\*\* \- enable the NETCONF Call Home feature. If set to 'true', each simulated device, when booting up, will try to Call Home to the SDN Controller.
 239
 240 * **ves** - container with settings for enabling or disabling VES features
 241
 242         \* \*\*faults\-enabled\*\* \- enable or disable faults over VES
 243
 244         \* \*\*pnf\-registration\*\* \- enable PNF registration on start
 245
 246         \* \*\*heartbeat\-period\*\* \- the number of seconds between VES heartbeat messages
 247
 248 ### Manager datastore changes mode of operation
 249 ===============================================
 250
 251 Changing any value from **sdn-controller** or **ves-endpoint** containers will be propagated to all running simulated network functions, and all new ones will use the values here. In the same manner, triggering any changes to the **fault-generation**, **netconf** and **ves** settings in a network function element from the *network-function* list will automatically propagate to all running network functions of the same *function-type*. However, changing the *docker-\** leafs of the *network-function* won't propagate, as they're only used as settings for starting new network functions.
 252
 253 ## NTS network function
 254 =======================
 255
 256 The NTS network function represents the actual simulated device.
 257
 258
 259 module: nts-network-function
 260
 261   +--rw simulation
 262
 263          +\-\-rw network\-function
 264
 265          |  +\-\-rw mount\-point\-addressing\-method?   enumeration
 266
 267          |  +\-\-rw fault\-generation
 268
 269          |  |  +\-\-rw fault\-delay\-list\* [index]
 270
 271          |  |  |  +\-\-rw index           uint16
 272
 273          |  |  |  +\-\-rw delay\-period?   uint16
 274
 275          |  |  +\-\-ro fault\-count {faults\-status}?
 276
 277          |  |     +\-\-ro normal?     uint32
 278
 279          |  |     +\-\-ro warning?    uint32
 280
 281          |  |     +\-\-ro minor?      uint32
 282
 283          |  |     +\-\-ro major?      uint32
 284
 285          |  |     +\-\-ro critical?   uint32
 286
 287          |  +\-\-rw netconf
 288
 289          |  |  +\-\-rw faults\-enabled?   boolean
 290
 291          |  |  +\-\-rw call\-home?        boolean
 292
 293          |  +\-\-rw ves
 294
 295          |     +\-\-rw faults\-enabled?     boolean
 296
 297          |     +\-\-rw pnf\-registration?   boolean
 298
 299          |     +\-\-rw heartbeat\-period?   uint16
 300
 301          +\-\-rw sdn\-controller
 302
 303          |  +\-\-rw controller\-ip?                       inet:ip\-address
 304
 305          |  +\-\-rw controller\-port?                     inet:port\-number
 306
 307          |  +\-\-rw controller\-netconf\-call\-home\-port?   inet:port\-number
 308
 309          |  +\-\-rw controller\-username?                 string
 310
 311          |  +\-\-rw controller\-password?                 string
 312
 313          +\-\-rw ves\-endpoint
 314
 315                 +\-\-rw ves\-endpoint\-protocol?      enumeration
 316
 317                 +\-\-rw ves\-endpoint\-ip?            inet:ip\-address
 318
 319                 +\-\-rw ves\-endpoint\-port?          inet:port\-number
 320
 321                 +\-\-rw ves\-endpoint\-auth\-method?   authentication\-method\-type
 322
 323                 +\-\-rw ves\-endpoint\-username?      string
 324
 325                 +\-\-rw ves\-endpoint\-password?      string
 326
 327                 +\-\-rw ves\-endpoint\-certificate?   string
 328
 329   rpcs:
 330
 331         +\-\-\-x datastore\-random\-populate
 332
 333         |  +\-\-ro output
 334
 335         |     +\-\-ro status    enumeration
 336
 337         +\-\-\-x feature\-control
 338
 339         |  +\-\-\-w input
 340
 341         |  |  +\-\-\-w features    ntsc:feature\-type
 342
 343         |  +\-\-ro output
 344
 345         |     +\-\-ro status    enumeration
 346
 347         +\-\-\-x invoke\-notification
 348
 349         |  +\-\-\-w input
 350
 351         |  |  +\-\-\-w notification\-format    enumeration
 352
 353         |  |  +\-\-\-w notification\-object    string
 354
 355         |  +\-\-ro output
 356
 357         |     +\-\-ro status    enumeration
 358
 359         +\-\-\-x invoke\-ves\-pm\-file\-ready
 360
 361         |  +\-\-\-w input
 362
 363         |  |  +\-\-\-w file\-location    string
 364
 365         |  +\-\-ro output
 366
 367         |     +\-\-ro status    enumeration
 368
 369         +\-\-\-x clear\-fault\-counters
 370
 371            +\-\-ro output
 372
 373                   +\-\-ro status    enumeration
 374
 375
 376 ### Detailed information about the YANG attributes
 377 ==================================================
 378
 379 All de details and mechanisms of the **network-function** container are explained in the **NTS Manager** section. Besides this container, there are also a couple of RPCs defined:
 380
 381 * **datastore-random-populate** - calling this will trigger the network function to populate all its datastore with random data, and based on the *config.json* defined rules
 382
 383 * **feature-control** - calling this will enable selected features. currently available features are:
 384
 385         \* \*\*ves\-file\-ready\*\* \- enables VES file ready, and stats a FTP and a SFTP server on the network function
 386
 387         \* \*\*ves\-heartbeat\*\* \- enabled VES heartbeat feature
 388
 389         \* \*\*ves\-pnf\-registration\*\* \- enables VES PNF registration
 390
 391         \* \*\*manual\-notification\-generation\*\* \- enables the manual notification generation feature
 392
 393         \* \*\*netconf\-call\-home\*\* \- enables NETCONF's Call Home feature
 394
 395         \* \*\*web\-cut\-through\*\* \- enables web cut through, adding the info to the ietf\-system module
 396
 397 * **invoke-notification** - this RPC is used for forcing a simulated device to send a NETCONF notification, as defined by the user.
 398
 399         \- The \*\*input\*\* needed by the RPC:
 400
 401                 \- \*\*notification\-format\*\* \- can be either \*json\* or \*xml\*
 402
 403                 \- \*\*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.\*\*
 404
 405         \- The \*\*output\*\* returned by the RPC:
 406
 407                 \- \*\*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.
 408
 409 * **invoke-ves-pm-file-ready** - as name impiles, it invokes a file ready VES request, with a specified *file-location*
 410
 411 * **clear-fault-counters** - clears all counters for the fault generation system. see **Fault generation** below.
 412
 413 ### Network function operation
 414 ==============================
 415
 416 Under usual operation, the network functions are managed by the manager which will perform the operations listed below. However, if a user chooses to, it can manually start up a network function, and manage it via NETCONF (datastore and RPCs).
 417
 418 1. Create and start Docker container
 419
 420 2. Set the VES and SDN controller data via NETCONF
 421
 422 3. Invoke **datastore-random-populate** RPC to populate the datastore
 423
 424 4. Invoke **feature-control**, enabling **ALL** the features.
 425
 426 ### Datastore random population
 427 ===============================
 428
 429 The datastore will be populated with random values on each of its leafs. However, certain there is some control on the population itself, which can be found in *config.json*, which is commented. Please note that the nodes below should be main nodes in *config.json*:
 430
 431
 432 "debug-max-string-size" : 50,       //max size of string. if not set, default is 255
 433
 434 "populate-rules" : {
 435
 436         "excluded\-modules": [           //modules to be excluded from populating
 437
 438                 "sysrepo",
 439
 440                 "sysrepo\-monitoring",
 441
 442                 "ietf\-yang\-library",
 443
 444                 "ietf\-netconf\-acm",
 445
 446                 "ietf\-netconf\-monitoring",
 447
 448                 "nc\-notifications",
 449
 450                 "ietf\-keystore",
 451
 452                 "ietf\-truststore",
 453
 454                 "ietf\-system",
 455
 456                 "ietf\-netconf\-server"
 457
 458         ],
 459
 460         "default\-list\-instances": 1,    //default number of instances a list or a leaflist should be populated with
 461
 462         "custom\-list\-instances" : [     //custom number of list instances. instance is schema name, and should reflect a list or a leaflist
 463
 464                 {"/ietf\-interfaces:interfaces/interface": 2}, //2 instances of this. if 0, list will be excluded from populating
 465
 466         ],
 467
 468         "restrict\-schema" : [           //restrictions to certain schema nodes to a set of values (so no random here)
 469
 470                 {"/ietf\-interfaces:interfaces/interface/type" : ["iana\-if\-type:ethernetCsmacd", "other\-value"]},
 471
 472                 {"/ietf\-interfaces:interfaces/interface/name" : ["name1", "name2"]}
 473
 474         ]
 475
 476 }
 477
 478
 479 ### Fault generation
 480 ====================
 481
 482 Fault generation is controlled using a combination of JSON and YANG settings.
 483
 484 From the JSON perspective, the settings are as below:
 485
 486
 487 "alarm-rules" : {
 488
 489         "yang\-notif\-template" : "<xml ... %%severity%%  $$time$$  %%custom1%%>",
 490
 491         "choosing\-method" : "random | linear",
 492
 493         "alarms" : [
 494
 495                 {
 496
 497                         //ves mandatory fields
 498
 499                         "condition" : "",
 500
 501                         "object"    : "",
 502
 503                         "severity"  : "",
 504
 505                         "date\-time" : "$$time$$",
 506
 507                         "specific\-problem" : "",
 508
 509                         //template custom fileds
 510
 511                         "custom1" : "",
 512
 513                         "custom2" : ""
 514
 515                 }
 516
 517                 ...
 518
 519                 {
 520
 521                         ...
 522
 523                 }
 524
 525         ]
 526
 527 }
 528
 529
 530 * **alarm-rules** node should be a main node in *config.json* for the respective network function in order for the fault generation to be enabled
 531
 532         \* \*\*yang\-notif\-template\*\* \- template of the yang notification model in current network function. can be "" to disable notifications. must always be present
 533
 534         \* \*\*choosing\-method\*\* \- method to choose the alarm. can be either \*linear\* or \*random\*, and must always be present
 535
 536         \* \*\*alarms\*\* list of alarms to choose from by "choosing\-method". it can contain any number of fields, custom ones, along with the mandatory VES fields presented below:
 537
 538                 \* \*\*condition\*\*
 539
 540                 \* \*\*object\*\*
 541
 542                 \* \*\*severity\*\* \- should correspond to VES defined: NORMAL, WARNING, MINOR, MAJOR, CRITICAL (case sensitive)
 543
 544                 \* \*\*date\-time\*\*
 545
 546                 \* \*\*specific\-problem\*\*
 547
 548 On the **yang-notif-template** and on any of the fields, there are two options for creating "dynamic" content (also see example above):
 549
 550 * **variables** - any field put in between %% will be replaced with the field's value
 551
 552 * **functions** - function names are put in between $$. Available functions are:
 553
 554         \* \*\*time\*\* \- returns current timestamp in a YANG date\-time format
 555
 556         \* \*\*uint8\_counter\*\* \- a unique 8\-bit counter, starting from 0, each time this function is found, the counter is automatically increased; when going above the max value, it will reset from 0
 557
 558         \* \*\*uint16\_counter\*\* \- a unique 16\-bit counter, starting from 0, each time this function is found, the counter is automatically increased; when going above the max value, it will reset from 0
 559
 560         \* \*\*uint32\_counter\*\* \- a unique 32\-bit counter, starting from 0, each time this function is found, the counter is automatically increased; when going above the max value, it will reset from 0
 561
 562 It is worth to mention that the replacement is done within any field, of any field. This means that it is possible to have nested fields and functions. See example for better understanding.
 563
 564 From the YANG perspective, one can control whether faults are enabled or disabled independently via NETCONF and/or VES, through their respective containers described in the sections above. The YANG **fault-generation** container contains:
 565
 566 * **fault-delay-list** - a list with elements which consists of *index* (unimportant, but needs to be unique) and *delay-period* which represents the number of seconds in between the current fault and the next fault. Please note that the fault is chosen from and based on the settings esablished in *config.json*
 567
 568 * **fault-count** - the status of the faults encountered by the network function; it is not present in the manager's schema
 569
 570 In order to clear the **fault-count** counters, on the **network-function** module there is a **clear-fault-counters** RPC which can be called via NETCONF.
 571
 572 ## NTS Application
 573 ==================
 574
 575 Either of the two main functionalities (*manager* and *network-function*) are implemented by the same binary application. Besides this functionality, the application can also do some utility functions, which can be used if the application is ran from the CLI (command line interface), along with some parameters.
 576
 577 ### CLI paramters
 578 =================
 579
 580 The paramers are described below:
 581 - --help - shows the help (also described here)
 582 - --docker-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**
 583 - the two main modes:
 584
 585         \- \-\-manager \- runs in manager mode
 586
 587         \- \-\-network\-function \- runs in network function mode
 588
 589     - global settings, which can be used with **ANY** of the other operating modes:
 590
 591         \- \-\-operational\-only \- used in testing. do not use the RUNNING datastore, only do the population on OPERATIONAL datastore
 592
 593         \- \-\-fixed\-rand \- used in testing. specify a fixed value seed for the randomness
 594
 595         \- \-\-verbose \- set the verbose level. can range from 0 to 2, default is 1
 596
 597         \- \-\-workspace \- set the current working workspace. the workspace must contain the \*config\* and \*log\* folders
 598
 599 - test modes - do not use
 600
 601 - utilitary functions:
 602
 603         \- \-\-ls \- list all modules in the datastore with their attributes
 604
 605         \- \-\-schema \- list the schema of an xpath given as parameter
 606
 607         \- \-\-populate \- populate the datastore upon starting
 608
 609         \- \-\-enable\-features \- enable all features upon starting, after (if requested) the populating was done
 610
 611         \- \-\-nc\-server\-init \- initialize netconf server
 612
 613         \- \-\-loop \- after everything is done, run an endless loop
 614
 615 ### Docker container initialization
 616 ===================================
 617
 618 The NTS app is responsible for initializing the Docker container upon build. What it actually does is described below:
 619
 620 1. Install modules located in the *deploy/yang/* folder recusively
 621
 622         \- note that if a module requires startup data (mandatory data), this can be acheived by having an \*\*XML\*\* file with this data along the YANG file. For example, if, let's say \*ietf\-interfaces.yang\* would require startup date, there must be a \*ietf\-interfaces.xml\* located in the same folder.
 623
 624 2. Enable all YANG features of the modules, unless specifically excluded
 625
 626 If the initialization failes, the result is returned to the Docker builder, so the build will fail, and user can see the output. Docker initialization can be customized from the *config.json* file, as described below. The example is self-expainatory, and the *docker-rules* node needs to be a main node of *config.json*:
 627
 628
 629 "docker-rules": {
 630
 631         "excluded\-modules": [          //excluded modules from installing
 632
 633                 "module1",
 634
 635                 "module2"
 636
 637         ],
 638
 639         "excluded\-features": [         //excluded features from installing
 640
 641                 "feature1",
 642
 643                 "feature2"
 644
 645         ]
 646
 647 }
 648
 649
 650 # Usage
 651 =======
 652
 653 The NTS Manager can be used to start any type of simulated network function.
 654
 655 ## Building the images
 656 ======================
 657
 658 The `nts_build.sh` script should be used for building the docker images needed by the NTS to the local machine. This will create docker images for the Manager and for each type of simulated network function.
 659
 660 The user can also directly use the already built docker images, that are pushed to the highstreet docker repository. This can be done by using the `nts*pull*highstreet_repo.sh` script, which will pull all the images locally.
 661
 662 ## Starting the NTS Manager
 663 ===========================
 664
 665 The **nts-manager-ng** can be started using the docker-compose file in this repo. The file assumes that the docker images were pulled from the highstreet docker repository.
 666
 667
 668 docker-compose up
 669
 670
 671 Before starting, the user should set the environment variables defined in the docker-compose file according to his needs:
 672
 673 * **NETCONF*NTS*HOST_IP**: an IP address from the host, which should be used by systems outside the local machine to address the simulators;
 674
 675 * **NETCONF*NTS*HOST*BASE*PORT**: the port from where the allocation for the simulated network functions should start;
 676
 677 * **IPv6Enabled**: should be set to `true` if IPv6 is enabled in the docker daemon and the user wants to use IPv6 to address the simulated  network functions.
 678
 679 # Release notes
 680 ===============
 681 ## version 1.0.3
 682 ================
 683 - [fixed] fixed issues where ODL could not parse the correct versions for yang files
 684
 685 ## version 1.0.2
 686 ================
 687 - [fixed] bug that occured when trying to start a wrong instance (bad docker-repository or docker-tag)
 688 - [fixed] when populating the fault-delay-list, if the sum of all the faults was 0, the network funciton kept on generating faults and crashed
 689
 690 ## version 1.0.1
 691 ================
 692 - [feature-add] added web-cut-through feature
 693 - [fixed] mount-point-addressing-method was mistakenly changing after starting
 694
 695 ## version 1.0.0
 696 ================
 697
 698 Initial release.
 699