# 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.2 Kubernetes-Based Agent Management  
In this work we propose to manage the agents' docker containers through Kubernetes. The choice of Kubernetes is based on the necessity of providing scalability and intelligent computational management in order to support large scale SDN DON emulated scenarios. Kubernetes has a wide range of benefits for virtualised systems that could help to accomplish the expected targets, e.g., service discovery and load balancing, storage orchestration, automated rollouts and rollbacks or self-healing just to mention a few. Moreover, Kubernetes is currently one of the most popular DevOps tools for container management, hence with a large support in the community [38]. Additionally, Kubernetes and Docker are complementary technologies, Kubernetes orchestrates one or more hosts that run containers, and Docker is the technology that starts, stops, and also manages those containers. In our model, Docker is a low-level technology orchestrated and managed by Kubernetes. To complement the justification about why Kubernetes is key in our proposal, we present a present a representative use case. Consider a need to emulate a full SDN-based DON scenario assuming realistic functionalities, with multiple optical nodes and at each node multiple optical devices such as, transponders, wavelength selective switches, EDFA amplifiers or optical channel monitor. Just considering a 25-node optical network and for these four types of devices, 25 \(\times\) 4 = 100 agents are needed, in the most favourable case assuming only 1 device per type and node (in reality this number is much higher). For  
Figure 2: Architectural details of the proposal: (**a**) General overview of the architecture for the Advanced Automatic Deployment of an emulated software-defined networking (SDN) disaggregated optical network (DON) framework; (**b**) Schema of the elements in a generic optical network agent. this case alone, managing 100 agents instantiated in virtual machines or virtual containers without intelligent management, the scenario is completely unaffordable for one single personal computer, computationally speaking. This is where Kubernetes comes in; this tool not only provides intelligent management of containers (agents), but its automatic load balancing and the minimization of the usage of computational resources, both features related to scalability, among others, are basic to allow the emulation of realistic and large-scale SDN DON scenarios. Thus, one of the major benefits that Kubernetes brings to our work is that it allows the emulation of complex SDN DON scenarios running on a single laptop, this way exploiting the potential usability and exploitation of our framework (e.g., teaching, academia, SDN DON pre-deployment phases, etc.). From an implementation perspective, we follow a traditional master nodes approach. A Kubernetes cluster is made up of one master and one or more nodes, as can be seen in Figure 3. Both master and nodes are Linux hosts that run on anything from VMs, bare metal servers, to private and public cloud instances. The Kubernetes master is composed of a set of small services that conform the control plane of the cluster and it can be externally accessed by the _kubctl_ service, a RESTful API or a graphical dashboard, all managed by the _kube_ API-server. The configuration and status of the cluster gets persistently stored in the _etcd_, while the controller implements the functionalities for controlling the Kubernetes cluster, such as, the node controller or the endpoints controller. Finally, the Kubernetes master offers the possibility to monitor new workloads and assign them to the nodes. Still regarding Figure 3, the nodes can be seen as clients in a server-client architecture, with the master as server. The nodes are where the containers are hosted in correspondence to the agents in our framework. Within the nodes, there are independent spaces to run the containers, called pods. One node can have several pods and in each pod several containers.