Add README.md

applications/rtdt-manager/README.md

+### Introduction
+This is the rtdt-manager (real-time digital twin manager) Proof-of-Concept application for managing Network Digital Twins (NDT) written
+for my (Sebastian Heiß) Bachelor Thesis "Consideration of Change Rates in Network Digital Twins".
+Its purpose is to demonstrate a mechanism of how a Digital Twin of a network managed by goSDN could be generated, launched
+and most importantly, kept synchronized with the initial physical network. Inspiration was taken from Neil Schark's venv-manager,
+however since that application was defunct, it was determined that it would be simpler to write this from the ground up.
+
+### Building
+You can clone and build this program like this:
+```
+git clone git@code.fbi.h-da.de:danet/gosdn.git
+make build-gosdn
+make containerize-gosdn
+make build-rtdt-manager
+```
+
+The application relies on building a local gnmi-target first based on the `interface-enabled-test` branch. For this, clone the gnmi-target repo:
+```
+git clone git@code.fbi.h-da.de:danet/gnmi-target.git
+git checkout interface-enabled-test
+make all
+
+```
+The file under `yang/yang.go` was copied from the danet gnmi-target repo ([https://code.fbi.h-da.de/danet/gnmi-target](https://code.fbi.h-da.de/danet/gnmi-target)) after building it with `make all`.
+It is necessary so that YANG paths received through events in the callback function can be parsed and their type can be extracted. This is the mechanism
+used to replicate changes from the Physical Network to the Network Digital Twin (See [#Theory of Operation](#theory-of-operation)).
+
+Starting the application is done for example like this:
+```
+./artifacts/rtdt-manager -u admin -a 172.100.0.5:55055 -p TestPassword -c applications/rtdt-manager/data/base-clab.yaml --sdnconfig applications/rtdt-manager/test/downloaded-config.json --with-twin
+```
+
+### Theory of Operation
+The application expects a .yaml containerlab topology file which specifies the base gosdn environment that should be used.
+It also takes a .json SDN configuration file which mirrors the Topology MongoDB collection. This specifies how the physical network looks.
+In a use-case with an actual physical network that uses arist switches, this would be assumed to be just retrievable from the database directly.
+
+When starting up, the application first creates the physical network. It does this by first taking the base Containerlab .yaml file to configure the physical network and to
+determine the addresses and configuration of the goSDN Controller, Plugin-Registry, MongoDB and MongoDB-Express, and RabbitMQ and then extracting the rest of the topology
+from the SDN-config file in .json. This is combined into a Containerlab configuration that specifies the entire physical network and once this has been deployed with Containerlab,
+the .json file is applied to the MongoDB database store with the Northbound Interface (NBI) configuration management service.
+
+After this, a NDT is launched by retrieving the Topology information from the Database and recombining it into a Containerlab yaml file with the base Containerlab file passed in
+earlier. The IP addresses are transposed to avoid conflicts in Docker and the Digital Twin network has its own instances of RabbitMQ, MongoDB, etc.
+
+The rtdt-manager subscribes to specific events in the physical network and a callback is triggered when these events occur. In this callback, the YANG path of the data that experienced a change
+as well as the new value can be retrieved and are applied to the NDT.
+
+### Additional Changes to Code
+The code expects there to be a local Docker image for gnmi-target called `gnmi-target-local`. For this, you can clone the gnmi-target repo (see Section [#Building](#building)) and checkout the `interface-enabled-test`.
+The Makefile in this branch was modified to build this image.
+
+Some changes to the goSDN controller were also necessary. In order to specify the location of the Plugin Registry and the MongoDB database dynamically without a config file, CLI switches were added.
+Additionally, there were some things that did not work properly like importing (applying) a SDN coniguration file that was previously exported (retrieved) because the plugin entries in the network elements
+did not exist.
+