See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/331339337

Demonstration of Container-based Microservices SDN Control platform for

Open Optical Networks

Conference Paper · January 2019

DOI: 10.1364/OFC.2019.M3Z.5

CITATIONS READS
2 103

6 authors, including:

Quan Pham Van Huy Quang Tran

Nokia Bell Labs USA Institut Mines-Télécom
16 PUBLICATIONS   77 CITATIONS    3 PUBLICATIONS   4 CITATIONS   

SEE PROFILE SEE PROFILE

Dominique Verchere Huu-Trung Thieu

Nokia Nokia Bell Labs
83 PUBLICATIONS   581 CITATIONS    6 PUBLICATIONS   31 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

SENDATE View project

Open Disaggregated Transport Networks View project

All content following this page was uploaded by Dominique Verchere on 26 September 2020.

The user has requested enhancement of the downloaded file.

 Demonstration of Container-based Microservices
SDN Control platform for Open Optical Networks
Quan Pham-Van1 , Huy Tran-Quang2 , Dominique Verchere1 , Patricia Layec1 ,
Huu-Trung Thieu1 , and Djamal Zeghlache2
1-NOKIA Bell Labs France, Nozay, 91260, France ; 2-Telecom-Sudparis, Evry, 91110, France
quan.pham van@nokia.com
Abstract: We demonstrate a microservices SDN control platform that provides network con-
trol plane as a service with the capabilities to instantiate, upgrade, automated and on-demand
deployment of the control components such as the controller and its applications.
OCIS codes: (060.4250) Networks; (060.4510) Optical Communications.
1. Overview
The traditional approach of the control and management of the optical networks is shifting along with the rapid
advances in software-defined networking (SDN) technology. The separation of control and data plane pushed the de-
velopment of the logically centralized control plane. Current open source projects (e.g., ONOS, ODL) are monolithic
software integrating both SDN controller and its applications, which is simple to test and deploy. As more applications
and features are being developed and integrated to SDN control platform, the limitations of monolithic software ap-
pear: addition of new features requites to be planned to rebuild and redeploy the controller, scalibity of IT resources,
hard to maintain the source code, etc..
The control plane platform needs enhanced capability of instantiating, upgrade, automated and on-demand deploy-
ment of SDN controllers and the applications such as path computation, defragmentation, re-optimization, recovery or
quality of transmission, etc.. to be adapted to the specifics of the optical network infrastructures [1]. This requires an
evolution in the control plane architecture from monolithic to microservices, which includes the SDN controllers and
the SDN applications.
Most of the studies listed in [2] have been done to solve the controller placement problem considering a variety of
objectives such as minimizing the latency between controllers and their connected switches, enhancing reliability of
the control network, or minimizing deployment cost and energy consumption. These previous studies are at the level of
algorithm design and performance evaluation. The issues regarding how first to apply a controller placement algorithm
and then to deploy or migrate the SDN controllers and the SDN applications in a real network control plane platform
has not been addressed yet, including with an experimental prototype.
To address these challenges, we present and demonstrate here a container-based microservices SDN control plane
platform for open disaggregated optical networks.
2. Innovation

Fig. 1: Monolithic vs Microservices SDN control plane.

Current SDN control plane is based on the monolithic architecture which is one software stack integrating SDN
controller and its applications as shown in Figure1 (left). In this demo, we rather rely on the microservices archi-
tecture with Docker container [3] technology to allow both (i) network control platform as a service, automated and
on-demand deployment of SDN controllers or applications, (ii) on-the-fly upgrades or swap of the software compo-
nents. In the container-based microservices, the controllers and its applications are built as an independent component
running inside the docker containers, as shown in Figure1 (right), that communicate over a messaging system (e.g.,
Rest/Restconf). This allows the applications to be developed in any programming language (e.g., C, Java, Python),
hence to rely on its own libraries, and to be independently tested. This container-based microservices SDN control
platform enables automation of Continuous Integration/Continuous Delivery (CI/CD) which reduces CAPEX and
OPEX of SDN software development and operations. The controllers and its applications are managed and orches-
trated by an orchestrator combined with CI/CD tools such as Git and Jenkins to automate the testing and validation of
each element. As shown in the Figure1 (right), the orchestrator allocates the IT resources for each software compo-
nents such as CPU, memory.
We implement and demonstrate the OpenConfig [4]/NETCONF southbound interface and T-API/RESTCONF [5]
northbound interface on both ONOS and ODL opensource controllers to configure and control a real open optical dis-
aggregated network platform composed of the commercial devices. We show a 4-step scenario: step 1 - control plane
deployment, step 2- optical service provisioning via T-API, step 3 - controller replacement (swapping) (e.g. changing
from ONOS to ODL) and step 4 – optical service restoration. the step 3 is the most innovative step which is depicted
in Figure2. The controller replacement process is divided into 2 phases:

Fig. 2: Detailed controller replacement workflow.

• Controller deployment: the deployment manager (DM) of orchestrator receives the controller replacement request in
a TOSCA template (yaml) via its REST interface. DM forwards the template to TOSCA Parser to extract the content
and validate the request. When the request is validated, DM sends a controller placement request to Placement
module. Placement module queries the resource state of the infrastructure to run the controller placement algorithm.
After, Placement module sends the output of placement algorithm to the DM. DM constructs a deployment template
and sends it to the virtual infrastructure manager (Kubernetes [6] in this case) to deploy a new SDN controller
instance. This step also applies to deploy any control plane component.
• Controller migration: when a new controller instance is deployed, DM queries the device’s information, e.g., IP
address or port, from current controller and registers these devices to the new controller. This triggers the new con-
troller instance to establish the control channels to the devices. The new controller discovers the device information
including its configuration and its state and it constructs the T-API topology context. At this point there is no control
command sent by new controller to the devices. Next, DM sends the commands to connect the applications to new
controller instance and it removes the current controller instance.
3. OFC relevance and demonstration
During the demo, we show and explain the container-based microservices SDN control plane to OFC audience. In
particular, how we can swap on-the-fly components with a hitless approach. The demo will be presented on-site via
 Fig. 3: Demonstration set-up and scenarios.
Orchestrator and SDN controllers GUI’s (ONOS, ODL) relying on the remote connections to our optical infrastruc-
ture lab. Our optical infrastructure testbed is shown in 3c and composed of 5 OpenConfig devices (3 ROADMs and
2 transponders), 2 OpenFlow switches and 2 computers for video streaming application. Figure 3b details the op-
tical network infrastructure. The ONOS and OpenDaylight controllers are used together with two control function
applications: routing and spectrum allocation [7], and optical service restoration application. The 4-step scenario, as
illustrated in 3a, is performed as follows from Orchestrator GUI:
• Step 1: control plane deployment - we perform drag and drop to select the components that are going to be in-
stantiated to compose the SDN control plane platform. In particular, we show ONOS controller, Path Computation
application, and optical service restoration application. It demonstrates network control platform as a service. ONOS
controller establishes the control channels with the devices, discovers the devices description thanks to OpenCon-
fig/NETCONF and constructs the T-API topology context.
• Step 2: optical service provisioning – we send a T-API service creation request between transponder 1 and 2 (bidirec-
tional service). This request handled by ONOS and path computation application is to provision the optical channel
going through ROADM1 and ROADM3. ONOS controller sends the NETCONF commands to two transponders to
create a frame mapping between the client ports (OpenFlow Switches) and line ports (optical channel). When the
optical service is successfully created, a video streaming is shown.
• Step 3: controller replacement - we now select ODL controller to replace the current ONOS controller. The controller
replacement procedure is performed as described in previous section.
• Step 4: optical service restoration - we switch-off an interface of ROADM1 to emulate the fiber cut scenario, hence
the video streaming stops. ODL controller receives a loss of power alarm. The optical service restoration application
is informed by ODL controller and then calculates a new path going through ROADM1, ROADM2 and ROADM3,
the devices along the new path are reconfigured. The video streaming restarts.
This work was partially supported by Celtic Plus SENDATE-TANDEM project (Project-ID: C2015/3-2)
References
1. Ramon Casellas et al, “On-Demand Allocation of Control Plane Functions via SDN/NFV for Monitoring-
enabled Flexi-grid Optical Networks with Programmable BVTs,” in ECOC, 2016.
2. Guodong Wang et al, “The Controller Placement Problem in Software Defined Networking: A Survey,” IEEE
Network , pp. 21 - 27, 2017.
3. “https://www.docker.com/,”.
4. OpenConfig “https://github.com/openconfig/public/tree/master/release/models/optical-transport,”, 2018.
5. Transport API, “https://github.com OpenNetworkingFoundation/TAPI,” 2018.
6. “https://kubernetes.io/,”.
7. Quan Pham-Van et al, “Virtualized routing and spectrum allocation function in Elastic Optical Networks”, in
ECOC, 2016.

View publication stats