A traffic-aware controller design for next generation ... - IEEE Xplore

2013 First International Black Sea Conference on Communications and Networking (BlackSeaCom)

A Traffic-Aware Controller Design for Next Generation Software Defined Networks Zemre Arslan, Arda Alemdaroglu and Berk Canberk Computer Engineering Department, Faculty of Computer and Informatics Istanbul Technical University Ayazaga 34469, Istanbul-Turkey Emails: {arslanz, alemdaroglu, canberk}@itu.edu.tr Abstract—The tremendous increase in the mobile traffic requirements and the growing demands of large scale Cloud data centers have lead the network administrators to seek new management approaches. The Software Defined Networks (SDN) has raised as a promising solution providing more effective, programmable and granular configurations in order to isolate all the dynamic traffic requirements and spiky changes in the physical topological status of the networks from the network management. In this paper, we propose a novel SDN Controller which classifies the network traffic types according to the heterogeneous Quality of Service requirements that the network data is separated into the Constant Bit Rate (CBR) based realtime traffic and File Transfer Protocol (FTP) based non-real time traffic. Some crucial traffic flow parameters such as packet delivery ratio, routing overhead and delay are also considered in this classification. A novel protocol header is also generated by the proposed SDN controller in order to disseminate the necessary information through the L2/L3 switches in the Data Plane. This header is composed of the Parameter, Rule, Controller Action subfields. The proposed SDN controller decides the most effective network deployment strategy, i.e. either becoming an ad-hoc or being centralized, using the traffic types, network parameters and the header information. A detailed performance evaluation is provided which indicates the efficiency of the proposed SDN controller while deciding necessary deployment considering the heterogeneous traffic types as well as the increased number of users in the topology.

I. I NTRODUCTION With the increased data traffic demands, the efficient and fair management of the current network configurations has become a time-consuming and expensive challenge. Especially, the dynamic changes in the mobile traffic density as well as the unpredictable movements of the end-users make the physical topology management and the feasible maintenance of current networks a more complex and difficult task to handle with resource-intensive efforts. Beside the dynamic traffic requirements and high mobility, the growing demands of very large scale data centers which are bound to the popular Cloud-based applications have lead the network administrators to seek new network management approaches. To this end, the Software Defined Networks (SDN) has raised as a solution providing more effective and granular configurations in order to isolate all the dynamic traffic requirements and spiky changes in the physical topological status of the networks from the traffic control and network management.

978-1-4799-0857-8/13/$31.00 ©2013 IEEE

SDN has emerged as a promising architectural solution to handle the resource management and maintenance challenges in future network deployments. SDN decouples the Data Plane which consists of L2/L3 forwarding devices (switches, routers) physically carrying all data packets, from the Control Plane which are basically the forwarding and routing information for all the flows [1]. Using SDN, the dynamic traffic demands can be controlled in a centralized and software based manner. The SDN-aware L2/L3 forwarding devices in the Data Plane and User-Defined programmable Controller in the Control Plane communicate via the OpenFlow protocol to easily operate and manage, and to be better able to respond to the changing demands of applications to the network conditions [2], [3]. While bringing an enormous flexibility in data flow optimization thanks to the programmable and centralized controller, some important challenges has to be mitigated for scalable and robust SDN deployments. One important challenge is to be aware of heterogeneous traffic types such as real-time (rt) and non-real time (nrt) traffic. Here, the rt and nrt traffic flows should be intelligently managed considering several Quality of Service (QoS) parameters such as throughput, delay, jitter, routing overhead, packet drop rate and packet delivery ratio. Moreover, the signaling overhead during the dissemination of the forwarding information from the Controller among all the SDN switches should also taken into consideration for SDNbased system designs. Scalability and robustness are other important concepts in SDN architectures. Being a new paradigm in the literature, there exist some efforts regarding the SDN-based systems and deployments. [4] draws the generic framework of SDN while bringing important challenges. The OpenFlow protocol is discussed in details in [5] by giving possible applications scenarios in Cloud System and some other large scale network deployments. [6] discusses future implementation using SDN systems. In [7], the authors propose a scalable SDN Controller which is strictly based on reducing the number of beacon messages disseminated by it. [8] provides some aspects of SDN related to transport networking, summarizes major drivers and trends. [9] implements an inter-AS and SDN based routing algorithm in order to forward huge amount of data in large scale networks. An OpenFlow based approach is proposed in [10] which is specifically implemented into the sensor networks.

167

2013 First International Black Sea Conference on Communications and Networking (BlackSeaCom)

[11] proposes a 3G specific SDN approach and claims that such an implementation will lower costs, increase efficiency, will allow for smooth evolution of network deployment from 3G.[12] proposes a scalable SDN architecture and network virtualization in which the users are assigned with abstract network addresses and topologies. [13] analyses different network virtualization implementation by generic frameworks. [14] identifies the current state-of-the-art network configuration and management mechanisms in SDN configuration and introduces mechanisms to improve various aspects of network management. In all the aforementioned studies, the heterogeneous traffic requests and flows have not been considered in the SDN system designs. However, the difference in the traffic, i.e. the real time and non-real time traffic, should be also analyzed to maintain a fair load balancing and an effective network topology management in future SDN-based systems. Moreover, the information of data forwarding and flow routing which is disseminated from the central controller should be carefully managed. Considering these motivations, in this paper we propose the following contributions: • The SDN Controller is proposed which classifies the network traffic types according to the Quality of Service requirements that the network data is separated into the Constant Bit Rate (CBR) based traffic with realtime traffic and File Transfer Protocol (FTP) based nonreal time traffic. Some crucial traffic parameters such as packet drop rate, routing overhead, delay and packet delivery ratio are also considered in this classification. • The proposed SDN Controller disseminates the necessary information to the L2/L3 switches in the Data Plane using a novel SDN header format. This header is composed of the Parameter, Rule,Controller Action subfields. • The proposed SDN controller decides the most effective network deployment strategy, i.e. either becoming an adhoc or being centralized, using the traffic types, network performance parameters and the header information. The rest of the paper is organized as follows: In Section II, we introduce the system architecture and the proposed framework. In Section III, the performance of the proposed scheme is evaluated in terms of different traffic parameters such as delay, jitter, packet loss ratio, packet delivery ratio and routing overhead. We conclude the paper by summarizing the achievements and giving future directions in Section IV. II. T HE N ETWORK A RCHITECTURE AND T HE P ROPOSED F RAMEWORK A. Network Architecture In order to do a performance evaluation in different scale SDN-based topologies, we constructed a model of mobile devices which are communicating each other with homogenous and heterogeneous traffic flows in a certain area. One SDN-controlled topology is structured with wireless mobile devices communicating with each other without any constituted network infrastructure i.e. without a Base Station. On

the contrary, in the other considered topology, wireless mobile devices are communicating each other through a base station. In both topology types we consider, i.e centralized and adhoc, the roaming of devices are disabled and the positions are kept static to obtain statistical data with utmost accuracy. Both the ad-hoc and centralized topology performance evaluation results give us a reference point about how to control the flow of data throughout a network that have different node densities and different background traffic. Our network model is also based on an increasing density of mobile devices with different traffic types. Here, we examined the SDN deployment for 4, 8 and 16 mobile devices which are representing low, medium and high density deployments of devices. The communication between wireless devices are established as pairs and the performance evaluation parameters are calculated for different traffic types such as homogenous CBR (Constant Bit Rate) over UDP (User Datagram Protocol) traffic stream, homogenous FTP (File Transfer Protocol) over TCP (Transmission Control Protocol) traffic stream, and heterogeneous traffic flow including both CBR over UDP and FTP over TCP with different percentages of mixing. The communicating pairs kept as same for each of the cases, thus the positions and the distances cannot affect the results; only the density and the background traffic flows affect the results. Both in heterogeneous and homogenous simulations, the SDN controlled traffic flow is sustained from the beginning to the end of the simulation without ceasing any traffic type flow, so that any other traffic type has no priority over another in a certain amount of time. As routing protocol, DSDV (DestinationSequenced Distance Vector) is used in both centralized and adhoc simulations, since DSDV performs sufficiently well with both infrastructure mode and ad-hoc mode. B. The Proposed Framework From small scale to large scale network media, the complexity of the network management increases when the data flow decisions are made with a physical infrastructure. Therefore, the management architecture should be more hardwareindependent, dynamic and automated. In order to automate the management and reduce the costs, we are proposing a software defined deployment strategy for networks as seen in Fig. 1. With our model, we would like to simplify the data flow decisions in SDN-based topologies, that have different-density node deployments. Our framework will be implemented as software, running on a management server. The management server will provide the necessary routing behavior information before the pairs directly communicate. As seen in Fig. 1, the proposed SDN framework is composed of two different planes. The Control Plane has a Controller in which we decide appropriate deployment strategies according to the heterogeneous traffic and QoS network criteria. The Controller disseminates the decisions using a special header as seen in Fig. 1. The proposed SDN Controller which can be seen in Fig. 2, based on two main parts; the controller and the header. In the controller module, the Node Classifier, permanently

168

2013 First International Black Sea Conference on Communications and Networking (BlackSeaCom)

Control Plane

Controller

SDN Header

OpenFlow Data Plane

SDN Header

SDN Header SDN Header

L2/L3 forwarding device

L2/L3 forwarding device

L2/L3 forwarding device

Wireless User Devices Fig. 1.

The Proposed Framework

checks the number of communicating nodes in the given area and passes this parameter to the main algorithm. The model also gathers the data of the traffic types transmitted in the background. Decision Layer or Control Plane acts based on these data inputs, and the final decision depends on the network parameters of Delay, Packet Delivery Ratio and Routing Overload. The controller of the framework is also preprogrammed to evaluate the priorities of the aforementioned network parameters. This priority control mechanism is crucial since the network managers may have different dependency requirements on the network parameters; while one may need shorter transmission times, another may need to minimize the routing load in the network or may want to balance these parameters. By analyzing the values of all these parameters and data, our model proposes to the nodes either directly talk with each other or communicate through a base station. The header which is the main output of the proposed Controller as in Fig. 2, has three subfields which are detailed as follows: • Parameter: This subfield contains the necessary network parameters which are Packet Delivery Ratio, Delay and Routing Overhead. All these three parameters are mathematically analyzed by the Controller seen in Fig. 1 as follows. – Packet Delivery Ratio, P DR(i) for ith wireless user’s traffic flow, shows how successful a protocol performs delivering packets from source to desti(i) nation. Ns implies the sent packet count from a (i) sender, Nr implies the received packet count with the same packet identifier numbers and n indicates the node numbers in the topology. PDR is calculated as: i

P DR =

n (i)  Nr i=1

(i)

Ns

∀i

(1)

. – Total Average Delay, D (i) for ith wireless user’s traffic flow, is measurement of total average time

passes between the release of a packet and the arrival (i) of the same packet to its destination. Ts implies the release time of a data packet from the agent of (i) the sender, Tr implies the received time of a data packet by its destination agent, n implies the node numbers and S (i) , implies the sent packet count. n (i) (i) (Tr − Ts ) n ∀i (2) Di = i=1 (i) i=1 S . – Routing Overload, R(i) for ith wireless user’s traffic flow, indicates the ratio of packets sent from the MAC layer of the nodes for sustaining the connectivity between other nodes in the topology and (i) for keeping the routing tables updated. Rp implies total routing packets sent through simulation time (i) and Sp implies the total amount of agent-sourced sent packets. Routing overload R(i) is calculated as below: R(i) = •

•

(i)

Rp

(i)

Sp

∀i

(3)

. Rule: This subfield is specified by the user and used to define what network parameters should be used in order to have the most effective deployment scenario. Controller Action: Using the necessary network parameter and rule, this field is filled with the appropriate action. This action can be either to deploy the wireless devices in an ad-hoc or centralized manner. III. P ERFORMANCE E VALUATION

We have evaluated some important performance evaluation parameters for both ad-hoc and centralized topologies which are Packet Delivery Ratio, Average Delay and Routing Overload. Simulations are done with the discrete event simulator, Network Simulator 2 (NS2). The output files of the simulations, namely trace files are examined with Python scripts.

169

2013 First International Black Sea Conference on Communications and Networking (BlackSeaCom)

Node Classifier

Traffic type

Deployment Control: Centralized or Adhoc?

Network metrics

Parameter

Fig. 2.

Rule

Controller

Controller Action Header

The Proposed SDN Controller

TABLE I C ONFIGURATION PARAMETERS

Non − Real Time Traffic Application P rotocol T ransport P rotocol P acket Size Send Interval W indow Size

FTP TCP 1040 Bytes 0.002Mbps 20

Real Time Traffic Application P rotocol T ransport P rotocol P acket Size Send Interval

CBR UDP 1000 Bytes 0.01Mbps

A. Comparison of Performance Evaluation Results for Different Topological Scenarios In our simulations, we defined some configuration parameters for different traffic types. These configuration parameters can be seen from Table I. For Non-Real Time Traffic, FTP over TCP traffic flow, the default packet size is 1000 bytes, but while releasing the packet from its sender, the simulation puts additional 40 bytes into the packet header, so the final size of one FTP packet is 1040 bytes. In each simulation, we wanted to keep the size of all data packets similar for a fair comparison; hence we defined the size of the CBR packets as 1000 bytes. Data send intervals are also kept with their default values. The packet send intervals are not changed because CBR packets can arrive their destinations in a short time if no collision or loop occurs, while FTP packets occupy their source and destination nodes with additional acknowledgement packets due to the handshaking mechanism of TCP; so the average lifetime of FTP packets are longer than CBR packets. By keeping the send interval with the default values, we tried to keep CBR and FTP packet delivery ratios similar in a certain amount of time. As seen in Figs. 3(a), 3(b) and 3(c) while the node density increases, in both SDN-controlled centralized and ad-hoc

topologies, the packet delivery ratio decreases as expected; but in centralized topologies, the success on the delivery process, especially for high node density deployment medium, is more in the centralized topologies compared to the ad-hoc topologies. When we consider the background traffic flows, the heterogeneous traffic causes a drastic fall on the delivery ratio, but this change is far less than it is in the delivery ratio, when the node deployment is dense. As it is also clearly seen from the graphics, ad-hoc structure does not work well in the heterogeneous background traffic flow as much as it does in homogenous traffic background. In the light of all these deductions, our controller will propose centralized communication when the node density is high and it will propose ad-hoc communication when the node density is low. Additionally, when the background traffic gets more heterogeneous ad-hoc communication performance decreases more than it decreases in centralized communication; in this situation the controller will decide to centralized communication. As it is seen in Figs. 3(d), 3(e) and 3(f) which are showing the results of average delay; in the centralized topologies, the average delay is substantially short. When the traffic flow is homogenous, performance of ad-hoc deployments on average delay is not good as it is for centralized topologies but the difference on average delay performance gets larger on heterogeneous traffic streams and the ad-hoc topologies fall behind the centralized topologies in this respect. Routing overload is another performance criteria which is analyzed for the topology decision of the control plane of our proposed model. As seen in Figs. 3(g), 3(h) and 3(i) graphics which are showing the routing overload results, routing load of centralized topologies are higher than the adhoc topologies since the packets of authentication, association and scanning processes in centralized structures occupying the whole simulation for a significant amount of time. When we consider the general characteristics of the graphics about average delay and routing overhead, centralized SDN structures have higher performance on the average delay parameter; and ad-hoc SDN structures have higher performance on routing load. At this point, our controller will consider the performance evaluation metics and their priorities; it will evaluate the inputs and at the end, it will choose the most appropriate structure for communcation. IV. C ONCLUSION In this paper, a control and decide mechanism is proposed to get the utmost performance by evaluating the QoS parameters. This is realized by a Software Defined Network approach with a controller structure. The considered network traffic is separated into the Constant Bit Rate (CBR) based traffic with real-time traffic and File Transfer Protocol (FTP) based nonreal time traffic. Some crucial network performance criteria such as packet drop rate, routing overhead, average delay and packet delivery ratio are also considered in this classification. A novel protocol header is also generated by the proposed SDN controller in order to disseminate the necessary information to the L2/L3 switches in the Data Plane. The evaluations

170

2013 First International Black Sea Conference on Communications and Networking (BlackSeaCom)

   



























 


















 

(a)






(b)

   

 

) * #%+

 






  



() *+

 

 !"#

  ! "# $%&

 

$ %&!'&#



'( )  *

!"#$%&'#(













(c)

  



"# $ %



  

  



$ %  &'"(

"#   $ % 







 !  

!"#  

 !

















    













 








   

(d)







   ! " #





    





    



   








   !

(g)

(h)

Fig. 3.












$%   "& 





" #$%& !'

      !





  



(!)  *#&+!





     

(f)

  



"#  $  % 






(e)

   
















     



(i)

SDN Controller Performances of Heterogeneous Traffic Types for Different Topological Scenarios

show that the performance of an SDN based system depends on QoS parameters such as delay, routing load and jitter on the coverage area which can change over time and affect the manageability of the network. R EFERENCES [1] Open Networking Foundation, “Software-defined networking: The new norm for networks,” White Paper, 2012. [2] N. M. et al, “Openflow: Enabling innovation in campus networks,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008. [3] C. Sher Decusatis, A. Carranza, and C. DeCusatis, “Communication within clouds: open standards and proprietary protocols for data center networking,” IEEE Communications Magazine, vol. 50, no. 9, pp. 26– 33, 2012. [4] D. Staessens, S. Sharma, D. Colle, M. Pickavet, and P. Demeester, “Software defined networking: Meeting carrier grade requirements,” in 18th IEEE Workshop on Local Metropolitan Area Networks (LANMAN), 2011, pp. 1–6. [5] S. Vaughan-Nichols, “Openflow: The next generation of the network?” Computer, vol. 44, no. 8, pp. 13–15, 2011.

[6] F. de Oliveira Silva, J. de Souza Pereira, P. Rosa, and S. Kofuji, “Enabling future internet architecture research and experimentation by using software defined networking,” in European Workshop on Software Defined Networking (EWSDN), 2012, pp. 73–78. [7] D. Levin, A. Wundsam, B. Heller, N. Handigol, and A. Feldmann, “Logically centralized state distribution trade-offs in software defined networks,” in SIGCOMM, HotSDN, 2012. [8] D. Mcdysan, “Software defined networking opportunities for transport,” IEEE Communications Magazine, vol. 51, no. 3, pp. 28–31, 2013. [9] R. Bennesby, P. Fonseca, E. Mota, and A. Passito, “An inter-as routing component for software-defined networks,” in IEEE Network Operations and Management Symposium (NOMS), 2012, pp. 138–145. [10] T. Luo, H.-P. Tan, and T. Quek, “Sensor openflow: Enabling softwaredefined wireless sensor networks,” IEEE Communications Letters, vol. 16, no. 11, pp. 1896–1899, 2012. [11] Nokia-Siemens Networks, “Liquid net: Core network virtualization a proof-of-concept,” White Paper, 2012. [12] D. Drutskoy, E. Keller, and J. Rexford, “Scalable network virtualization in software-defined networks,” IEEE Internet Computing, vol. 17, no. 2, pp. 20–27, 2013. [13] M. C. et.al, “Network functions virtualization,” in the SDN and OpenFlow World Congress, 2012. [14] H. Kim and N. Feamster, “Improving network management with software defined networking,” IEEE Communications Magazine, vol. 51, no. 2, pp. 114–119, 2013.

171