Design and Implementation of MPLS SDN Controller
Application based on OpenDaylight
Emir Husni
School of Electrical Engineering and Informatics
Institut Teknologi Bandung
Bandung, Indonesia
ehusni@lskk.ee.itb.ac.id
Abstract—This paper discusses design and implementation of
SDN Controller application in a Multi-Protocol Label Switching
(MPLS) network based on OpenDaylight. In this paper, we first
briefly review Traffic Engineering challenges in MPLS networks.
We then discuss on how Software-Defined Networking (SDN)
could overcome Label Switched Path (LSP) path calculation
challenges in MPLS Traffic Engineering. We discuss that a
centralized SDN Controller has network-wide visibility thus
should become “source of truth” of network state. We discuss
that OpenDaylight has capabilities as centralized SDN
Controller, however one needs to build application on top of
OpenDaylight. An application of SDN Controller based on
OpenDaylight is proposed in this paper. To verify the application
functionalities, a virtual lab is created to model an MPLS
network and an OpenDaylight SDN Controller. A performance
measurement of the OpenDaylight SDN Controller is also
discussed in this paper.
Keywords—MPLS TE, SDN, OpenDaylight
I. INTRODUCTION
Traffic Engineering (TE) in MPLS network has been one of
the key challenges in service provider environment. That is
because service provider wants to optimize network resources
such as link capacity and traffic route. Traffic engineering itself
is a mechanism to control traffic path in the network [1]. There
are three objectives of Traffic Engineering [2]:
• Optimize the use of network resource by avoiding
congestion while there is still sub-optimal network
resource, thus increases the amount of traffic carried by
the network.
• Provides Quality of Service on customer traffic.
• Provides reliability during failure.
There are several TE approaches in MPLS network: using
MPLS TE Label Switched Path (LSP) [3], Interior Gateway
Protocol (IGP) TE [4] and Label Distribution Protocol (LDP)
TE [5]. Study [3] shows that TE using LSP is the most
optimized method among others, and yet still poses challenges
in its implementation due to inflexibility of explicit path
calculation done by the router. Several offline path
computation tools are available to provide explicit path
calculation based on certain parameters such as delay, weight
978-1-5386-3779-1/18/$31.00 ©2018 IEEE
Adhy Bramantyo
School of Electrical Engineering and Informatics
Institut Teknologi Bandung
Bandung, Indonesia
and distance thus better result can be achieved. However, the
configuration consistency and up-to-date global network view
are the main issues faced by the offline path computation tool.
Software-Defined Networking (SDN) is an emerging
network architecture concept with the objectives to facilitate
network evolution and virtualization. Open Networking
Foundation (ONF) defines SDN as a technology which
separates the control plane and forwarding plane, and is
programmable [6]. SDN architecture contains three layers:
infrastructure layer, control layer and application layer. Each
layer is connected through an interface: South Bound Interface
(SBI) which connects infrastructure layer and control layer and
North Bound Interface (NBI) which connects control layer and
application layer as shown in Fig. 1.
Integration of SDN and MPLS has sparked the interest of
service provider mainly because [7]:
• SDN provides centralized control therefore reduce
network operational complexity
• Ease network monitoring and diagnostics
• Simplify and accelerate innovation
• Optimize network resource and reduce operational
cost
There are several approaches on MPLS SDN integration:
using OpenFlow protocol [8], Hybrid MPLS [9] and PCE
architecture [10]. While the three approaches use separation of
control plane and forwarding plane, PCE architecture approach
gives a more flexible implementation, as it does not require
massive configuration changes on existing MPLS network
devices. This paper discusses about how the MPLS SDN
Controller based on the Active-Stateful PCE architecture can
be used to overcome challenges in today's service provider
network. OpenDaylight, an open source implementation of
Active-Stateful PCE, is used as SDN Controller.
The remainder of this paper is organized as follows. Active-
Stateful PCE is discussed in Section 2. Design of SDN
Controller application is discussed in Section 3.
Implementation and verification of SDN Controller application
are discussed in Section 4. Section 5 discusses performance
measurement of SDN controller. This paper concludes in
Section 6.
 Provider Edge (PE) router where LSP was initiated. Service
abstraction layer in OpenDaylight would process data received
by SBI. It included service notification subscription and data
modeling. OpenDaylight used YANG language to model
network device configuration. REST API as an NBI, provided
the applications for the data storage in the controller. It
supported OPTIONS, GET, PUT, POST and DELETE. The
output of Restconf could be in XML or JSON format. The
applications on top of OpenDaylight were responsible for the
LSP path calculation as OpenDaylight did not provide it. Fig. 2
shows Active-Stateful PCE architecture using OpenDaylight.

III. DESIGN OF SDN CONTROLLER APPLICATION

The SDN controller application provided interface for user
to do LSP creation, modification and deletion. Application
interacted with Java Script (JS) and Python CGI as main
engines. The engines were responsible to communicate with
OpenDaylight for data manipulation.
Python scripts were used to manipulate data received from
OpenDaylight via REST API. The scripts parse required
Fig. 1. SDN Architecture Overview information such as network topology information, LSP
topology, LSP attributes. The data was stored in JSON format
and used by front-end framework for visualization.
II. ACTIVE-STATEFUL PCE
JS engine acted as front-end and accessible via web
A Path Computation Element (PCE) [10] is an entity such
interface. Bootstrap, an open source front-end framework, was
as a network component, application or device that has ability
used to create web-based SDN Controller application. D3.js
to calculate route in the network based on a network graph by
library was used to visualize network topology diagram while
applying certain parameters. A Path Computation Client (PCC)
the tabular data presentation was provided by jqGrid. To allow
is an application on the client, which requests path calculation
the post XML data form to the OpenDaylight REST API, a
to PCE. In the centralized PCE architecture, network device
proxy mechanism created by Python CGI was used. Fig. 3
acts as a PCC where PCC interface integrates with the router
shows the interaction between the SDN Controller GUI with
operating system. The PCE Protocol (PCEP) [11] defines a set
OpenDaylight and the network.
of communication messages between PCC and PCE. In its
operation, PCE requests a path setup to PCC via PCEP and The application consisted of three main functions: LSP
PCC sends the response to PCE containing LSP states in the creation, modification and deletion. On the LSP creation, the
network. PCEP is Transmission Control Protocol (TCP)-based application reads input from the GUI, calculated LSP path
protocol. using all_shortest_path algorithm available in Networkx
library, then sent required data in XML format to
The Active-Stateful PCE [12] is a mechanism allowing
OpenDaylight via REST API. OpenDaylight processed this
PCE to compute an LSP path pro-actively once LSP control is
input and sent a Pcinitiate message via PCEP to PCC in the
delegated to PCE. It also synchronizes all LSP states in the
router. LSP modification had similar steps as LSP creation
network.
except that Pcupdate message was the message sent to the
In our implementation of Active-Stateful PCE, PCC. LSP deletion required fewer steps than LSP creation and
OpenDaylight controller was used. It provided an SBI to modification as the LSP path calculation was not needed. LSP
communicate with network devices, a Service Abstraction deletion sent Pcinitiate with a remove-flag in SRP (Stateful
Layer (SAL) which processed data received from SBI and NBI, PCE Request Parameter) set to true. Fig. 4 shows a flowchart
which provided web Application Programming Interface (API) of LSP creation, modification and deletion.
for the web module inside abstraction layer to call.
BGP-LS and PCEP modules were used as SBI towards
network element. BGP-LS module was used to get a complete
view of the network topology from Traffic Engineering
Database (TED) exported by the router. TED was populated
from IGP protocol such as OSPF or IS-IS. A BGP session was
established between OpenDaylight and one router per area.
PCEP module was used to get LSP topology and to manage
LSP. It contained detailed information about the LSP such as
status, bandwidth, color, and Explicit Route Object (ERO). The
PCEP session must be established between OpenDaylight and
Fig. 2. Active-Stateful PCE Architecture

Fig. 4. Application Flow Chart

Fig. 3. Block Diagram of GUI Application

IV. PROTOTYPE AND TESTBED

To implement and verify application functionalities, a lab
using virtual environment was built. The testbed used in this
study consisted of an HP Proliant DL 380 G6 equipped with
dual Intel® Xeon™ X5570 2.93 GHz and 24 GB of RAM
running CentOS 6.7 with KVM and Qemu as a hypervisor.
There were seven Virtual Machines (VMs): six VMs to
simulate MPLS network and the other to host SDN Controller
system.
In our scenario, Juniper Networks vMX was used to
simulate an MPLS network consisting of three Provider Edge
(PE) routers and six Provider (P) routers. The vMX router
required two VMs, one for control plane (vMX-re) and the
other for the forwarding plane (vMX-pfe). Virtual networks
were required to connect vMX-re and vMX-pf (vmx_internal)
and vMX-pfe to other vMX-pfe (vmx_lan). Another VM was
used to host OPENDAYLIGHT and SDN controller
application. A CentOS 6.7 was used as the VM operating
system. Fig. 5 shows VM topology and MPLS topology built
on top of the VM.
Fig. 5. VM Setup and MPLS Network Topology

On the testbed, BGP-LS was configured in one router and

OpenDaylight, while PCEP required to be configured in
OpenDaylight and all PE routers. For PCEP, we used the latest
drafts: draft-ietf-pce-stateful-pce version 07 and draft-ietf-pce-
pce-initiated-00. Fig. 6 shows a GUI application with MPLS
network topology information and LSP information.

V. PERFORMANCE EVALUATION
In this section we will discuss the performance of SDN
Controller. Performance was measured by calculating the time
needed to set up a certain number of LSPs. Setup time was
started when posting xml input to OpenDaylight and
Fig. 6. GUI Application Showing Topology Diagram and LSP Information
Fig. 7. LSP Setup Time vs Number of LSP
ended when OpenDaylight receives information containing
LSP status.
We developed a python script that reads the xml input and sent
it to OpenDaylight via REST API. We had simulated the
process of LSP setup generation by number of LSPs from 2 to
800 LSPs. Each start and end time of the measurement was
collected from karaf.log file. During measurement, we
observed that OpenDaylight processed xml input data
sequentially per LSP. The result showed that LSP setup time
was proportional with the number of LSPs being set up with
LSP setup rate 3,2 LSPs/second. In practice, this rate is higher
than if a network operator use copy-and-paste of CLI
commands. This number could be improved if OpenDaylight
processed xml input in parallel fashion, instead of sequential.
In Fig. 7 we plot a curve of LSP setup time versus number of
LSPs.
VI. CONCLUSION
In this paper, we discussed the design and implementation
of SDN controller application based on OpenDaylight. We
verified the functionalities of the application by implementing
it on the virtual environment. We observed that OpenDaylight
provides functionalities needed to act as an SDN controller in
MPLS networks. It, however, does not provide LSP path
computation functionality. This function must be handled by
the application. Based on our observation, we conclude that
OpenDaylight is a promising approach of Active-Stateful PCE
implementation.
Nevertheless, several issues are still open for further
research. The GUI can be developed further to provide more
functions such as LSP visualization, instant network event
notification, diverse LSP design and calendar-based LSP
modification. Another issue related to OpenDaylight
performance that can be improved more is LSP setup rate. This
could be achieved by parallelizing LSP operation.
REFERENCES
[1] V. Agarwal, S. Saraswat, H.P. Gupta, T. Dutta, “A traffic engineering
framework for maximizing network revenue in software defined
network,” Proceedings of 10th International Conference on
Communication Systems & Networks (COMSNETS), pp. 531-533,
2018.
[2] D. Awduche, J. Malcolm, J. Agogbua, M. O’Dell, J. McManus,
“Requirements for Traffic Engineering Over MPLS”, September 1999.
[3] K. Xu, M. Shen, H. Liu, J. Liu, F. Li, T. Li, “Achieving Optimal Traffic
Engineering Using a Generalized Routing Framework,” IEEE
Transactions on Parallel and Distributed Systems, vol. 27, no. 1, pp. 51-
65, 2016.
[4] A. Cianfrani, M. Listanti, M. Polverini, “Incremental Deployment of
Segment Routing Into an ISP Network: a Traffic Engineering
Perspective,” IEEE/ACM Transactions on Networking, vol. 25, no. 5,
pp. 3146-3160, 2017.
[5] G. López, E. Grampín, “Scalability testing of legacy MPLS-based
Virtual Private Networks,” Proceedings of IEEE URUCON, pp. 1-4,
2017.
[6] ONF White paper, “Software-Defined Networking: The New Norm
form Networks”, Open Networking Foundation, April 2012.
[7] A. Farrel, “The Impact of SDN On MPLS Networks," 15th annual
conference –MPLS 2012, Juniper Networks, 2012.
[8] S. Das, A. Sharafat, G. Parulkar, N. McKeown, “MPLS with a Simple
OPEN Control Plane," Proceedings of Optical Fiber Communication
Conference and Exposition and the National Fiber Optic Engineers
Conference, pp. 1-3, 2011..
[9] A. Boava, Y. Iano, “Secure Inter-Cloud architecture for virtual cloud
computing based on hybrid IP and MPLS infrastructure solution,” IEEE
Latin America Transactions, vol. 14, no.7, pp. 3490-3495, 2016.
[10] A. Giorgetti, “Proactive H-PCE architecture with BGP-LS update for
multidomain elastic optical networks,” IEEE/OSA Journal of Optical
Communications and Networking, vol. 7, no. 11, pp. 1-9, 2015.
[11] J.S. Choi, “Controller-centric combinatorial wrap-around interaction
testing to evaluate a stateful PCE-based transport network architecture,”
IEEE/OSA Journal of Optical Communications and Networking, vol. 9,
no. 9, pp. 792-802, 2017.
[12] R. Casellas, R. Vilalta, R. Martínez, R. Muñoz, “Active stateful PCE
high-availability for the control of flexi-grid networks with network
function virtualization enabled replication,” Proceedings of Optical
Fiber Communications Conference and Exhibition (OFC), pp. 1-3, 2016.