Software Defined Networking for Telecom Operators: Architecture and Applications

2013 8th International Conference on Communications and Networking in China (CHINACOM) Software Defined Networking for Telecom Operators: Architecture and Applications Jian-Quan Wang China Unicom Research Institute Beijing 100032, China wangjq@chinaunicom.cn Haijing Fu International School of Beijing University of Posts and Telecommunications, Beijing 100876, China fuhj007@sina.com Chang Cao China United Network Communications Co.,Ltd., Postdoctoral Workstation, Beijing 100033, China caochang@chinaunicom.cn 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 SDN s architecture in an operator s 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 individual network devices, into accessible computing devices enables the underlying infrastructure to be abstracted for applications and network services, which can treat the network as a logical or virtual entity[3]. This allows network operators to define and manipulate logical maps of the network and therefore create multiple co-existing network slices (virtual networks) independent of underlying transport technology and network protocols [4]. Furthermore, the separation of control Fig.1 Architecture of SDN defined by ONF There are three layers in a SDN system, and a series of communication mechanism between them. Infrastructure layer consists of many network devices like routers, switch etc. Only a control agent is needed by every device to receive instruction from upper layer. No signal activity among each device when network is running. Control layer is the essential part in the system. 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 link s 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 SDN s architecture and related technologies in an operator s view in section 2. In Section 3, we describe some SDN s 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. II. ARCHITECTURE AND KEY TECHNOLOGIES OF SDN In an operator s 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 operator s 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 today s networking devices as monolithic, closed, and 829

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. 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. 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 level s 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 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 830

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 traffic s 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 link s condition of congestion. The whole model of control can be illustrated as Fig.4. 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 machine s migration. Correspondingly, the network deployment or policies (like IP address, bandwidth location, and firewall) that accompany with the virtual machine s 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 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 router s condition and control the router s throughput level. This controller will report each router s and link s 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 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 machine s 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 831

equipment in a metro network, the management for them is very difficult. With the help of SDN s 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. 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. 832

The algorithm in SDN controller can be customized by operators and it is able to control SDN equipment of different manufacturers. V. CONCLUSIONS The concept of SDN has been proposed for several years and some practical models have been introduced to guide IT and telecom manufacturer to develop related 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 SDN s 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. [8] Saurav Das, Ali Reza Sharafat, Guru Par, et al., MPLS with a Simple OPEN Control Plane, OFC2011, Los Angeles, USA, Mar.2011. [9] M. Yu et al., Scalable Flow-Based Networking with DIFANE, Proc. ACM Sigcomm, Aug. 2010. [10] S. Gringeri et al., Technical Considerations for Supporting Data Rates Beyond 100 Gb/s, IEEE Commun. Mag., vol. 50, no. 2, 2012, p. S21. 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. 69 74. [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 Int l. Conf. Optical Internet, Yokohama, Japan, May 29 31, 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