uABNO: A Cloud-Native Architecture for Optical SDN Controllers

: We present a cloud-native architecture for Optical SDN Controllers based on ABNO architecture and gRPC interfaces, which is demonstrated and evaluated. Autoscaling mechanisms for high request loads and auto-healing support are evaluated. © 2020 The Author(s)

The proposed uABNO internal architecture consist on microservices that interact using gRPC protocol buffers based on ONF Transport API. This conversion considers [5]. Moreover, a Cloud Orchestrator (such as Kubernetes) is responsible for lifecycle management of the microservices (including health checks and resource allocation). The uABNO microservices can be classified within three types: a) Database microservice, which provides a scalable cloud native database (such as MongoDb) for storing network element topology, status and configuration, as well as connectivity services requested and connections; b) HTTP microservice, which exposes uABNO NorthBound Interface (NBI) (e.g., ONF Transport API) as a RESTconf API and translates the request to internal protocol buffers; and c) gRPC microservices, which use gRPC protocol and protocol buffers as basis for intercommunication. Fig. 1 (left) shows proposed uABNO architecture. NBI microservice is responsible to interact with network operator's OSS/BSS and translate the connectivity requests into internal protocol buffers. The cloud-native database (Context implemented in MongoDb) is responsible for storing the context that includes controlled and managed connectivity services, connections and topologies. It interacts with their respective components in order to create, read, update and delete (CRUD) the records.
The internal architecture workflows are depicted in Fig. 1 (right). Once a connectivity service request is received, the NBI translates this request into the proper protocol buffer and sends the request to connectivity microservice. The connectivity microservice first requests a path computation to path computation microservice that requires a topology retrieval. Once a feasible path is computed, virtual network topology manager (VNTM) microservice is responsible for analyzing the need for multi-layer/multi-domain connections and generates the necessary connection requests towards the connection microservice. The connection microservice is responsible for requesting the necessary network element configuration (e.g., NETCONF, OpenFlow), or interacting with underlying SDN controllers.
The workflow for removing a connectivity service is also detailed in Fig. 1 (right). The NBI receives a connectivity service delete request, which is forwarded to connectivity microservice. Connectivity microservice requests to connection microservice the deletion of the related connections.
This proposed cloud-native architecture has several key benefits that introduce network automation: a) self-healing properties, due to the constant monitoring of microservices and restart of them in case of failure; b) auto-scaling, which allows to monitor microservice resource consumption and scale the microservice horizontally in case of overload (path computation is a resource consuming process which easily scales horizontally); c) load balancing, related to auto-scaling, in the sense that it allows to balance the load between replicated microservices; and d) automated roll-backs, which allow the declarative network status description, benefiting network operators with network programmability.

Autoscaling and self-healing microservices
The inherent features from a Cloud Orchestrator such as Kubernetes provide the necessary support for two key features that are required for a modern Optical SDN controller: autoscaling and self-healing. uABNO microservices might benefit from Horizontal Pod Autoscaler (HPA) component of Cloud Orchestrator. A certain amount of CPU and memory resources are requested per microservice. HPA monitors the microservice behavior and notices if resource limit is reached. Then, a new replica is generated and load between replicas is balanced in order to reduce resource utilization. This feature is useful for resource consuming microservices such as path computation.
Another significant benefit from cloud-native orchestration is the introduction of monitoring the status of the microservices, using a health check regularly (if the service is serving request or not serving). In case of service bad health (which might be caused by some blocking external component or an unexpected microservice behavior), Cloud Orchestrator removes the current deployment of the microservice and a new replica is deployed. This is known as a self-healing mechanism.

Experimental results
The proposed uABNO architecture has been developed based on python container-based microservices, which use gRPC and protocol buffers interfaces to communicate between them. MongoDB has been deployed for context storage, including connectivity, connection and topology information. The connection component has several plugins in order to directly control NETCONF-based network elements or interact with REST-based optical SDN controllers. In our current setup, we have simulated a 14 node NSF network, where each node is managed by a NETCONF agent. A Kubernetes 1.15 cluster of two nodes using Intel NUC with i7, 32Gb RAM, 1Tb SSD has been deployed on top of ADRENALINE Testbed Cloud Platform. Istio and Kiali have been installed in order to monitor the microservices running on the cluster. A loadgenerator microservice has also been developed in order to stress the proposed architecture and obtain significant results of optical cloud-native SDN controller. Fig. 2.a shows the relationship between the deployed microservices. It can be observed that three types of protocol are introduced (HTTP orange/gRPC green/TCP blue). It also shows the aggregated latency (in average) between components. For example, a connectivity-service creation request might take 172ms, from these 94ms correspond to path computation, 60ms to VNTM, or 5ms to connection. Fig. 2.b shows the request duration from the NBI perspective. It can be observed that request duration varies depending if it is a connectivity service create request or a connectivity service delete request. Create requests average 150ms, while deletion requests average 30ms. Fig. 2.c provides an example of horizontal scaling behavior, after increasing path computation complexity in order to demonstrate auto-scaling properties. Once path computation delay reaches a certain threshold (meaning that more CPU resources are needed), a new replica of path computation microservices is deployed, thus leading to a reduction on path computation delay. Fig. 2.d shows the self-healing property, after emulating an error in connectivity microservice. The orchestrator automatically restarts the microservice within the configured timeout (150s).

Conclusions
We have successfully validated and demonstrated a novel cloud-native architecture for Optical SDN controllers. The proposed uABNO provides a higher degree of flexibility, stability and scalability than current monolithic SDN controllers. The application of cloud-native network control and management will provide network operators with a higher degree of network automation.