# Emulating Software-Defined Disaggregated Optical Networks in a Containerized Framework
## 2 Proposed Architecture for SDN-DON Emulation
### Advanced Automatic Deployment of Emulated SDN DON
#### 2.2.3 Versatile Agent Definition  
The second major contribution of this work is a novel definition of versatile optical agents that can be automatically instantiated. We present a generic definition of agents suitable not only for specific YANG models belonging to specific projects (e.g., Telecom Infra Project [37]) but also for all optical models that can be defined using the YANG language. This novel structure is decisive in the sense that a user can evaluate scenarios with a potentially infinite number of optical devices under the same emulation framework irrespective of their vendor, technology, or type. Therefore, this new functionality is critical not only to emulate DON scenarios with realistic current data models, but also to be compatible with all future data models using the YANG language.  
Figure 2b depicts the structure proposed for a generic agent that emulates the role of a software entity in charge of governing optical devices. It is composed of four major components, a NETCONF server, a YANG validator, an XML (eXtensible Markup Language) /JSON (JavaScript Object Notation) config database and the files of the YANG model necessary to emulate an optical device, all coming from open-source initiatives and they are implemented in one single Docker container. Further details follow:  
* NETCONF server: it provides NETCONF connectivity with the SDN controller with the aim at avoiding dependency of existing agent automation framework, similarly to the Sysrepo in the legacy work. In this work, the NETCONF skeleton is given by the Choppsv1 library [41] that supports both the creation of NETCONF clients and servers, however it does not provide the full implementation of the server. The _pyangbind_ module complements the server, because it permits the generation of automatic code from YANG files, the validation of XML calls, essential in NETCONF-based communications and XML/JSON conversion amplifying the potential for connectivity [42].
* YANG validator: _pyang_ is Python-based library playing the role of a validator, transformer, and generator of YANG code. It can be used for validating YANG modules, YANG modules transformation into different formats, and code generation from modules. This module is key to provide potential scalability and generalization [43].
* XML/JSON config database: it stores the configuration files related to the configuration of the agent for the different functional states, such as boot or running.
* YANG model files: finally, a set of YANG files that define the behaviour required to emulate an optical device. They are validated by the _pyang_ module.  
From a global point of view, it is worthwhile to indicate the interaction among the components described above. First, YANG models are provided, e.g., such as Cassini transponder models. Then, agents leverage on the YANG validator based on pyang for the creation of the NETCONF skeleton within the NETCONF server. Notably, it is worth recalling that SDN controllers commonly include a series of drivers that implement NETCONF client functionalities for interacting with the agents via NETCONF protocol. This interaction, on the agent side, will leverage on the pyangbind module for XML/JSON validation. Then, also in the NETCONF server side, custom instructions are implemented for interacting with the data plane. Finally, we report the interaction between control and data signals flow among the components in the next subsection. For instance, Figure 8 will showcase the interaction between agents (data plane) when connectivity is requested from the SDN controller (control plane).