# Emulating Software-Defined Disaggregated Optical Networks in a Containerized Framework
## 3 Proof-of-Concept Configuration  
In order to test and evaluate the emulation framework of this work, in this section we propose a proof-of-concept that integrates the key elements of the entire architecture. Here we detail the configuration and settings for performing such proof-of-concept.  
The proof-of-concept follows the design exposed in Figure 2a, with three main actors: (i) ONOS playing the role of SDN controller that interacts and configure the emulated optical data plane (set of agents in this case), (ii) Kubernetes, in charge of the management of the Docker containers where the optical agents are implemented, and finally (iii) the data plane, represented by the set of agents emulating the software that governs the optical devices. For the sake of simplicity, we only use an agent of Cassini transponder according to the OpenConfig project. All the evaluation system has been deployed and executed in a high-performance laptop (Intel 8 th generation i7 with 8 logical cores, 32 GB of 2400 MHz DDR4 RAM and 1 TB of SSD). Further details follow:  
* Agent definition and integration: a specific docker container is built to integrate the architecture proposed and described in Section 2.2.3 for an automatic agent deployment. The set of YANG files that replicate the behaviour of a Cassini transponder are extracted from the GitHub repository of the OpenConfig project [44]. Precisely, the files _openconfig-terminal-device.yang_, _openconfig-if-ethernet.yang_ and _openconfig-types.yang_ are stored in the YANG file catalogue of the agent container.
* Kubernetes configuration: following the structure presented in Figure 3 Kubernetes Cluster is installed in Linux, an Ubuntu distribution, and it is composed by one master and one worker node and one pod in this worker node. Agents' creation and configuration are driven by the _deploy.yaml_ file, see Figure 4, where it commands the deployment of the Docker containers. The service _kubctl_ is the one to execute the deployment of the agents where results of such deployment are presented in the next section.  
* ONOS: we chose a virtualized distribution of ONOS (version 2.3.0) in a Docker container. The installation using Docker also permits to open the necessary ports for this proof-of-concept in one single command as presented below. Port 8181 is used for external communication with ONOS via GUI, port 5005 is a Java debugger port, port 8101 permits command line interface (CLI) communication via CLI and the port 830 permits NETCONF-based connectivity. Finally, once the container is up and running, pertinent \"apps\" must be activated to enable the expected functionalities within the SDN controller framework: \"odtn-service\", \"roadm\" and \"optical-rest\". _docker run -t -d -p 8181:8181 -p 8101:8101 -p 5005:5005 -p 830:830 -name onos onosproject/mos:2.3.0_
* Topology definition: the topology is defined in a JSON file so that it can be interpreted by ONOS. Seven metrics can be set \"Devices\", \"links\", \"hosts\", \"Apps\", \"ports\", \"regions\" and \"layouts\". In this work we only use the objects \"device\" and \"link\". Each device object is linked to each container previously deployed by indicating some specific fields, such as IP of the container and port to enable NETCONF connectivity, ONOS driver or map location, as can be seen in the exemplary definition  
Figure 4: Containers deployment configuration script for Kubernetes.  
if Figure 5a. Moreover, the links define the interconnection between two agents by setting their IP and ports, type of connection or bidirectionality, among others as depicted in Figure 5b.  
Once the file is ready, it is sent via ONOS NBI API to inform the details of the topology. Topology definition and JSON file creation are performed manually in this proof-of-concept emulating the 18-nodes European Optical Network. Future works will target the automatization of this procedure.