2013 8th International Conference on Communications and Networking in China (CHINACOM)

Software Defined Networking for Telecom

Operators: Architecture and Applications
Beijing 100876, China
Jian-Quan Wang fuhj007@sina.com

China Unicom Research Institute

Beijing 100032, China Chang Cao
wangjq@chinaunicom.cn China United Network Communications Co.,Ltd.,
Postdoctoral Workstation,
Haijing Fu Beijing 100033, China

International School of Beijing University of Posts and caochang@chinaunicom.cn

Telecommunications,

Abstract-Software defined network (SDN) is an emerging
network architecture where control plane is decoupled
from forwarding and is directly programmable. SDN has
been studied by academic for several years and some
prototype have been developed and tested by industry. Here
we firstly analyze SDNs architecture in an operators view.
Then we discuss SDN applications for telecom networks
and its influence for the future.
plane and data plane makes the SDN a suitable candidate
for an integrated control plane supporting multiple
network domains and multiple transport technologies.
The architecture of SDN has been defined by open
networking foundation (ONF)[5] as shown in Fig.1.

Keywords-software defined network; openflow protocol;

telecom network;

I. INTRODUCTION
Software defined network (SDN) is defined as a
control framework that supports programmability of
network functions and protocols by decoupling the data
plane and the control plane, which are currently
integrated vertically in most network equipment[1,2].
This migration of control, formerly tightly bound in
Fig.1 Architecture of SDN defined by ONF
individual network devices, into accessible computing
devices enables the underlying infrastructure to be There are three layers in a SDN system, and a series
abstracted for applications and network services, which of communication mechanism between them.
can treat the network as a logical or virtual entity[3]. Infrastructure layer consists of many network devices
This allows network operators to define and manipulate like routers, switch etc. Only a control agent is needed by
logical maps of the network and therefore create multiple every device to receive instruction from upper layer.
co-existing network slices (virtual networks) independent No signal activity among each device when network is
of underlying transport technology and network running. Control layer is the essential part in the system.
protocols [4]. Furthermore, the separation of control Many intelligent algorithms are deployed in a network

828 978-1-4799-1406-7 2013 IEEE

controller to enable networking functions like routing,
bandwidth allocation, traffic engineering (TE) etc.
Application layer is the visual interface to response users
requirement and display network real-time status.
OpenFlow (OF)[6] is an open standard, vendor and
technology agnostic protocol that allows separation of
data and control plane and therefore it is a suitable
candidate for the realization of SDN. It is based on flow
switching with the capability to execute software/user
defined flow based routing, control and management in a
controller (i.e. OF controller) outside the data path. OF
extensions to support optical networks can provide a new
vendor agnostic framework for evolving carrier grade
networks. There are several APIs used as interface
between application layer and control layer, giving
management order from operating staff to the SDN
network.
As for the study of SDN, besides academic, like
worldwide universities and institutes, some companies
have attempted to deploy SDN for their real use. Internet
content providers (ICPs) like google are reported to use
SDN control to increase their backbone links throughput
from 40% to 95% for Internet data center (IDC)
interconnection[7]. HUAWEI, NEC, Big Switch have
demonstrated their routers and controller that support TE
functions with intelligent algorithms, and give many
possible application scenarios[8]. Telecom operators like
Deutsche Telecom and NTT also begin their study for
SDN, and the applications have extended from data
center network to other network areas, like backbone or
metro networks[9]. Key technologies that related to
operators requirement has been discussed in lots of
organizations like ITU-T SG13/SG15, 3GPP, GSMA and
ONF[10].
In this paper, we will briefly review the SDNs
architecture and related technologies in an operators
view in section 2. In Section 3, we describe some SDNs
under developed and promising applications for telecom
networks. In Section 4 we analyze the influence that
originated from SDN to future networks, and we
conclude the paper in Section 5.
829
II. ARCHITECTURE AND KEY TECHNOLOGIES
OF SDN
In an operators view, the architecture of SDN can be
described as Fig.2. Especially, a joint service platform is
requested to cooperate the work of different SDN
controllers that may developed by many manufacturer.
Some key technologies of each model in this architecture
are also shown in Fig.2.
Fig.2 The SDN architecture in a operators view
As is shown in Fig.2, the IT/Telecom manufacturer will
be responsible for the research and develop of SDN
devices, including OF switch, OF router and other IT
equipment that support SDN function.
SDN device: Since the whole control functions have
been transfer from device to controller, the SDN devices
will mainly focus on the hardware performance, like
chips processing speed, buffer size and storage capacity.
As a result, the cost and improvement of the device will
mostly obey Moore's Law, which will help telecom
operators to reduce the cost of equipment as time rolls.
SDN controller and OF protocol: Like the common SDN
architecture that defined by ONF, SDN controller is
decoupled from SDN devices and in charge of control
plane of networks. They are usually computers or servers
in a pool format. OpenFlow is the first standard
communications interface defined between the control
and forwarding layers of an SDN architecture. OpenFlow
allows direct access to and manipulation of the
forwarding plane of network devices such as switches
and routers, both physical and virtual (hypervisor-based).
It is the absence of an open interface to the forwarding
plane that has led to the characterization of todays
networking devices as monolithic, closed, and
mainframe-like. The OpenFlow protocol is implemented
on both sides of the interface between network
infrastructure devices and the SDN control software.
OpenFlow uses the concept of flows to identify network
traffic based on pre-defined match rules that can be
statically or dynamically programmed by the SDN
control software. It also allows IT to define how traffic
should flow through network devices based on
parameters such as usage patterns, applications, and
cloud resources.
API plugin: SDNs can be deployed today leveraging
existing APIs like CLI, SNMP, RADIUS, NETCONF,
XML, XMPP etc.
CLI (Command Line Interface) each vendor has their
own implementation, most of the time multiple different
CLIs exist within a vendor portfolio as they grew via
M&A. Even management/provisioning tools exist that
try to abstract the different vendor implementations they
are costly and only suited for large scale service
providers.
SNMP (Simple Network Management Protocol) similar
challenges exist as with the CLI along with the fact that a
lot of vendors use SNMP only for monitoring but not for
configuration and provisioning.
NETCONF (Network Configuration Protocol) this
protocol (RFC6241) has been largely focused on router
implementations and is not widely available in enterprise
products. Even extensible it is only suitable today for
router provisioning in service provider type deployments.
XMPP (Extensible Messaging and Presence Protocol)
RFC6120 has been developed to provide near-real-time
exchange of structured yet extensible data between any
two or more network entities. Even targeted at
applications around presence management it could be
used in different solutions as well.
Joint Service Platform: There is a platform combine the
NMS (network management system) function and flow
visor that customize by telecom operators, which is the
main feature of telecom levels SDN example. The
principle of joint service platform is shown in Fig.3.
There are three layers in this platform. The resource
management layer is deployed to classify different
830
network resource, including network resource
(information provided by telecom equipment),
calculation resource (IT information) and attachment
resource (firewall, load balance function etc). This layer
is directly connected with SDN controller and some IT
devices through API plugin. The core function layer is
response for the realization of algorithm. An external
model is connected with this layer and the program of
every network algorithm is located there, which can be
extended according to the conditions. The system
integration layer is used to implement the NMS functions,
which can be in a form of cloud platform, and add flow
visor as a windows for operating staff to manage the
SDN network. FlowVisor is an experimental
software-defined networking (SDN) controller that
enables network virtualization by dividing a physical
network into multiple logical networks. FlowVisor slices
a physical network into abstracted units of bandwidth,
topology, traffic and network device central processing
units (CPUs). It ensures that each controller touches
only the switches and resources assigned to it. It also
partitions bandwidth and flow table resources on each
switch and assigns those partitions to individual
controllers.
Fig.3 Principle of joint service platform
III. SDN APPLICATIONS FOR TELECOM
NETWORKS
Since the SDN gives a decoupling architecture for
network design, aiming to reduce the CAPX and OPEX
of networks, it can help the network vendors to focus on
key technologies of different network layer. There are
several applications have been discussed to introduce
SDN to telecom operators networks.
A. Data center interconnecting (DCI)
Since the data synchronization, backup, and traffic
pushing among different data centers can be predicted,
this kind of flow is able to be planned and arranged by
traffic engineering (TE), which will increase the
throughput of the backbone link and give the
optimization for traffics generating. Because SDN is
based on central control, it can integrate with TE
algorithms and bring the network traffic grooming
function after the controller get acquired of links
condition of congestion. The whole model of control can
be illustrated as Fig.4.
Fig.4 DCI implementation based on SDN model
As is shown in Fig.4, there are SDN routers in the egress
part of every data center, and an SDN controller can get
the routers condition and control the routers throughput
level. This controller will report each routers and links
information periodically to the central controller, which
has the global information of the network. The central
controller will integrate and analysis these status of every
link, and then give the order in a certain format to the TE
server, which will calculate the input parameters and
give the optimal choice to the routing path. This kind of
order will pass to the SDN gateway at first, and then
deliver to each router. After a period of time, the central
controller will collect these information again, and may
change the routing policy according to the network
conditions. As illustrated in Fig.4, if the directly link
between site 1 and site 4 is jammed, the SDN controller
831
will get this information and TE server will calculate
other two paths 1-2-4 and 1-3-4 to balance the traffic
load and reduce the latency.
B. Inside data center application
As for the quick development of virtual machine
technology, today IDC can provide cloud services with a
very limited set up time. As a result, the migration of
virtual machine will happen very often inside a data
center. The IT devices will be in charge of virtual
machines migration. Correspondingly, the network
deployment or policies (like IP address, bandwidth
location, and firewall) that accompany with the virtual
machines migration need to be finished in a very short
time. The SDN application inside the data center is
mainly used for helping the migration of network
policies, which is illustrate in Fig.5.
Fig.5 Demonstration of SDN application inside a data center
In Fig.5, there are two service areas in the data center,
and SDN switches are located to connect them. If a
request for setting up new cloud services has been
arrived, the IT devices will first find a suitable storage
and calculation resource, and then handle with the virtual
machines migration. Once the migration of virtual
machine has been finished, the openflow switch will
begin the migration of network policies, like bandwidth,
routing table and service id etc. The flowvisor also can
be used here to check the status of virtual machines, and
their network deployment can be demonstrated from the
flowvisor as well.
C. SDN for metro and access networks
As for the SDN deployment in metro and access
networks, there are mainly two applications. The first
one is the virtualization of wireless backhaul network, as
is shown in Fig.6. Since there are hundreds of access
equipment in a metro network, the management for them
is very difficult. With the help of SDNs centralization
control, almost all the equipment in an access ring can be
virtualized as one equipment, so the maintenance and
configuration for the access ring can be much easier. In
future, the aggregate and the core layer of wireless
backhaul network also can be virtualized, and the scale
of virtualization depends on the ability of the SDN
controller.
Fig.6 Virtualization of wireless backhaul network
The second application is using SDN to build the
broadband network gateway (BNG) pool for metro IP
networks. As is shown in Fig.7, SDN controller will
manage the SR/BRAS equipment, which are connect
with OLTs in access side, in order to set up and schedule
the services flexibly and quickly.
Fig.7 SDN controlled BNG Pool
IV. SDN AND FUTURE NETWORKS
Besides central control and quick response, another
main feature for SDN is that the decoupling architecture
of data plane and control plane, and related hardware and
software. These have been several new ideas to support
this kind of decoupling architecture or software defined
control, which may influence the development of future
network mostly.
832
Fixed Mobile Convergence (FMC): Fixed Mobile
Convergence is a transition point in the
telecommunications industry that will finally remove the
distinctions between fixed and mobile networks,
providing a superior experience to customers by creating
seamless services using a combination of fixed
broadband and local access wireless technologies to meet
their needs in homes, offices, other buildings and on the
go. As for the improvement of control technology, the
control plane will handle both fixed network and
wireless network from access layer to core layer. For
example, the future Bras and GGSN equipment could be
integrated, and provide home fiber link and wireless
access together and do not care the position of the user.
The authentication and the charging system of wired and
wireless will be integrated as well.
Software Defined Radio(SDR): is a radio
communication system where components that have
been typically implemented in hardware (e.g. mixers,
filters, amplifiers, modulators/demodulators, detectors,
etc.) are instead implemented by means of software on a
personal computer or embedded system. The ideal
receiver scheme would be to attach an analog-to-digital
converter to an antenna. A digital signal processor would
read the converter, and then its software would transform
the stream of data from the converter to any other form
the application requires. An ideal transmitter would be
similar. The SDN idea can be used for SDR and realize
the flexible control of essential transmission factor like
modulation format according to the distance and quality
of the wireless channel.
Telecom equipment with IT design: The cost of
telecom equipment is increasing all the time, with more
and more unnecessary function adding on it. Because the
manufacturer develop both hardware and software of
telecom devices, it is hard for operators to purchase
equipment according to their own request. However, the
cost of IT devices has been reduced all the time during
past many years, which thanks to the decoupling
architecture of hardware and software. The SDN idea
helps the separation of telecom equipment and their
control/management software, which will reduce the cost
of the equipment themselves and let operators to choose
necessary protocol and functions for their own network.
The algorithm in SDN controller can be customized by [8] Saurav Das, Ali Reza Sharafat, Guru Par, et al., MPLS with a

operators and it is able to control SDN equipment of Simple OPEN Control Plane, OFC2011, Los Angeles, USA,

different manufacturers. Mar.2011.

[9] M. Yu et al., Scalable Flow-Based Networking with DIFANE,
V. CONCLUSIONS
Proc. ACM Sigcomm, Aug. 2010.
The concept of SDN has been proposed for several [10] S. Gringeri et al., Technical Considerations for Supporting Data
years and some practical models have been introduced to Rates Beyond 100 Gb/s, IEEE Commun. Mag., vol. 50, no. 2,
guide IT and telecom manufacturer to develop related 2012, p. S21.
equipment. We conclude nowadays and future SDN
applications for telecom operators networks in this paper
and point that now it is a suitable time for operators to
build some experimental network to test SDNs
performance and improvement for networks. Through
more practical use of SDN equipment, controller and
joint platform, other applications will be involved with
SDN solutions as well, which will help us to find new
paths for future telecom networks.

ACKNOWLEDGMENT

This work is partially supported by the National

Basic Research Program (973 Program) of China under
grant No. 2009CB320907, National Key Technology
R&D Program under grant No. 2012BAH06B0, and
National Science and Technology Major Projects under
grant No.2010ZX03004-002-02.

REFERENCES
[1] N. McKeown et al., OpenFlow: Enabling Innovation in Campus
Networks, ACM SIGCOMM Computer Commun. Rev., vol. 38,
no. 2, Apr. 2008, pp. 6974.
[2] G. Goth, Software-Defined Networking Could Shake Up More
than Packets, IEEE Internet Computing, July/Aug. 2011.
[3] S. Shenker, The Future of Networking, and the Past of
Protocols, Open Networking Summit, Oct. 18, 2011.
[4] Isogai et al., Global-Scale Experiment on Multi-Domain
Software Defined Transport Network, 10th Intl. Conf. Optical
Internet, Yokohama, Japan, May 2931, 2012.
[5] Software-Defined Networking: The New Norm for Networks.
ONF White Paper. 2012.4.
[6] D. Verchere, Cloud Computing over Telecom Network, Proc. Of
OFC/NFOEC 2011, Los Angeles, CA, March 2011.
[7] S. Gringeri et al., Flexible Architectures for Optical Transport
Nodes and Networks, IEEE Commun. Mag., vol. 48, no. 7,
2010, p. 40.

833