Autonomous Domain Correlation-Based Cross-domain Network View Caching Method for SDN Distributed Controller

Transcription

1 Chinese Journal of Electronics Vol.25, No.6, Nov Autonomous Domain Correlation-Based Cross-domain Network View Caching Method for SDN Distributed Controller FU Tao 1,HULiang 1,2, CHAI Sheng 1,2 and CHE Xilong 1 (1. College of Computer Science and Technology, Jilin University, Changchun , China) (2. Key Laboratory of Symbolic Computing and Knowledge Engineering of Ministry of Education, Jilin University, Changchun , China) Abstract Software-defined networks (SDN) maintain a global view of the network, thus improving the intelligence of forwarding decisions. With the expansion of the network scale, distributed controllers are used in a variety of large-scale networks in which subnetworks managed by controller instance are called autonomous domains. We analyze statistic frequency of communication across the autonomous domain. We calculate the autonomous domain correlations for controller instances using acquired statistical information. We cache network views to highly correlated controller instances. Distributed controllers are capable of considering both the average response time and overall storage. An experiment shows that our method can fully take advantage of these two performance indicators. Key words Software-defined networks (SDN), Distributed controller, Network analyze, Network view cache. Typical distributed controllers are made of multiple single controller instances. Collaborative distributed controllers (CDC), such as Hyperflow [4],DISCO [5],ONOS [6], adopt a fully distributed architecture, in which each controller instance is an independent node and manages its own autonomous domain. These controller instances communicate via a West-east bound interface (WEI) [7 9],as showninfig.1. I. Introduction Software-defined networks (SDN) [1,2] are flexible and widely recognized as a viable solution to solve bottlenecks in conventional networks. The Openflow protocol [3] achieves facile reconfiguration of applications, protocols or even algorithms by forward-control separation and programmability, in which the centralized control plane maintains a global view of the network. A global view of an SDN network refers to information across the whole network concentrated in controllers and applications. Although it is relatively simple to implement a centralized global view and its consistency in single controllers, single controllers are being replaced by scalable distributed controllers because they become bottlenecks in large-scale networks. Fig. 1. Collaborative distributed controller A Hierarchical distributed controller (HDC) (e.g., Kandoo [10] ) adds a root controller on top of these controller instances to run complex applications [11 13].Kandoo s goal is to deploy applications to different controller instances based on their response time and frequency,as showninfig.2. Although distributed controllers are widely used and network applications continue to increase, the management of applications and their statuses has become very complicated. Managing a network view in a logically Manuscript Received Jan. 22, 2016; Accepted May 4, This work is supported by the European Seventh Framework Program (FP7) (No.GA ), the National Natural Science Foundation of China (No ), the National Sci-Tech Support Plan of China (No.2014BAH02F03), and Youth Science Foundation of Jilin Province of China (No JH). c 2016 Chinese Institute of Electronics. DOI: /cje

2 1128 Chinese Journal of Electronics 2016 centralized distributed controller is very complex work; many existing controllers achieve only a weak consistency model. In Ref.[14] it contains a section on the consistency of a distributed controller, which acknowledges that current distributed controllers accomplish weak consistency in network views among the controller instances. Thus, it is still difficult to achieve consistency in the global view at any time and every instance of logically centralized, physically distributed controllers. group. The algorithm automatically increases the resource usability in the distributed controller according to the network state. II. Related Work The network view is the most important piece of information in network analysis and directly affects routing decisions and the users quality of service. In a conventional network, each forwarding device collects the network information with a topology discovery protocol and monitoring applications. In SDN networks, the controller uses an LLDP [16] protocol to acquire the network view, such as Floodlight, NOX, and Beacon [17]. There are two main paradigms for distributed controllers in the storage network view: Shared database storage (SDS) and Collaborative storage (CS) (shown in Fig.3). Fig. 2. Hierarchical distributed controller Maintenance of a complete global view of each controller instance is consistent with the basic characteristic of SDN, but this program is difficult to achieve simultaneously on multiple controller instances. Moreover, network dataflow in terms of the number and data are inhomogeneous in time and space. In Ref.[15] it divides the global view into partitions and issues them to the controller instances to save storage. This paradigm trades off between the network view consistency of each controller instance and controller resource inner-occupancy. In this paper, we defined an SDN network view caching problem for distributed controllers based on dataflow inhomogeneity in time and space and statistics requests received by each controller instance. The contributions of this study are presented below: 1) We analyze SDN distributed controllers in terms of storage overhead, communication overhead and response time and present a model definition of cross-domain network view caching for SDN distributed controllers and its problems. 2) We consider network communication inhomogeneity in time and space; first, we collect real-time network information and analyze the autonomous domain correlation of controller instances; we then calculate the crossdomain network view caching scheme based on the associated autonomous domain correlations. 3) We design a grouping algorithm to group all instances in an SDN distributed controller; the controller instances whose autonomous domains have the highest autonomous domain correlation will be assigned to same Fig. 3. (a) Shared database storage; (b) Collaborative storage After gathering the information of network views in each autonomous domain, these two architectures take different approaches in the realization of a global view. SDS (Fig.3(a)) uses a remote database to centrally store the global view through a northbound interface; otherwise, CS (Fig.3(b)) uses a variety of interfaces to synchronize the network view, and the complete view of the network is ultimately saved on each controller instance. This type of controller is widely known and used. A hierarchical distributed controller (such as Kandoo) is also categorized into CS from the perspective of resource usage. Aiming at this problem, A universal method of application state slicing for distributed storage is proposed in Ref.[15], the advantage of which is to reduce the storage overhead of each controller instance. This article analyzed how to compute neither application dependency nor synchronization overhead.the work of this paper is different from the abovementioned research. Network view is the most important piece of information, we present standardized formulas for calculating the overhead of cross-domain network view caching. According to the computational results of the autonomous domain correlations, we sort the controller instances into different groups with a grouping algorithm. III. Problem Definition and Modeling Distributed controllers are logically centralized but physically distributed. The overall cost of the system must

3 Autonomous Domain Correlation-Based Cross-domain Network View Caching Method for SDN Distributed Controller 1129 be analyzed according to several key evaluation criteria such as storage, network bandwidth, and response time. Caching the cross-domain network view has an enormous impact on these three parameters, so we can design a cross-domain cache policy to handle these performance indicators. SDN cross-domain network view caching is inspired by application state partition research but is a Controller instance grouping (CIG) and maintains a shared network view in each group to strike a balance between information synchronization overhead and response time. According to the statistics of autonomous domain correlations associated with controller instances, distributed controllers make decisions on the required network view of controller instances, and cache network views all controller instances. The required variables are displayed in Table 1. Table 1. Definition of parameters Parameter Description Distributed controller architecture(sds, CS or A CIG). X A set of controller instances. x i A controller instance numbered with i. A network topology managed by a distributed controller A G (A) Autonomous domain managed by controller instance x i. g i Storage overhead under distributed controller architecture A. C M (A) Storage overhead in a network; may be one of subgraph g i managed by controller instance x i, DB C m(x i ) or G. Information synchronization overhead under architecture A. C SYN (A) Information synchronization overhead of g i managed by x i. C syn(x i ) The average response time of a request under architecture A. T res(a) Average round-trip time in network communications among devices. T rtt The time spent by the database to process data T lp for a request, which is proportional to the size of tables in the database. An average rate in which requests received by controller instances can be calculated in the network r(a) view of their autonomous region. A rate at which requests received by controller instance x i can be calculated in local view. r i N order matrix consisting of statistics computed L n with dataflow among n autonomous domains. The data statistics from one autonomous domain l n(i, j) of x i to the other of x j in matrix L n The data statistics from one autonomous domain l raw(i, j, k) of x j to the other of x k monitored by controller instance x i. The statistical value for all data received and sent l node (i) by controller instance x i. Group(A) A collection of groups under architecture A. group i A group numbered with i. η The overall cost of the distributed controller. Assuming that there is a distributed controller managing a complex network, each controller instance manipulates an autonomous domain. This network constitutes agraphg, and every controller x i has g i =(V gi, E gi ). We assume that the entire network is divided into w groups with the CIG model. 1. Network view storage overhead The network view storage overhead is the total cost of storing network views of all controller instances and the shared database. C M (A) is calculated below: C M (A) =C m (x 1 )+C m (x 2 )+ +C m (x n )+C m (DB) (1) 1) Total storage cost in SDS where G = g 1 + g g n,g DB = G, g i g j =Ø thus, C M (SDS)=2C M (G) 2) Total storage cost in CS where G = g 1 = g 2 = = g n,g DB =0 thus, C M (CS)=n C M (G) 3) Total storage cost in CIG w C M (CIG)= [ group j C m (x i )] j=1 x i group j +C m (DB) The calculation process of CIG storage first computes the total cost of a group; each controller instance requires the same information as the other controller instances in the same group, and the summed storage overhead on all controller instances of this group is the total cost of the group. We then compute the sum of the storage overhead of all groups and the storage overhead caused by the shared database. 2. Network view synchronization overhead Network view synchronization overhead refers to communication overhead for network view synchronization during network changes to synchronize network views of controller instances. Synchronization of SDS is relatively simple: every controller instance sends data to the shared database when the network changes. Network view synchronization of CS is very complex because controller instances broadcast their network view to other nodes to ensure that all controller instances are consistent. C SYN (A) iscalculated below: C SYN (A) =C syn (x 1 )+C syn (x 2 )+ + C syn (x n ) (2) 1) Total synchronization overheads in SDS C SYN (SDS)=C syn (x 1 )+C syn (x 2 )+ + C syn (x n ) = C syn (G)

4 1130 Chinese Journal of Electronics ) Total synchronization overheads in CS C SYN (CS) =(n 1)C syn (x 1 )+(n 1)C syn (x 2 )+ + C syn (x n ) =(n 1)C syn (G) 3) Total synchronization overheads in CIG C SYN (CIG)= w ( group j 1) C syn (x i ) x i group j j=1 CS produces large synchronization overhead because it broadcasts network views among controller instances in response to network variations. 3. Inner-domain computation rate Inner-domain computation rate (ICR) refers to the ratio of controller instances that respond to requests based on local data. If a controller instance receives requests whose match field includes an IP address that is out of range of the autonomous domain, this controller instance requires access to the shared database for more network views. 1) ICR of x i r i = l n(i, i) (3) l node (i) where n l n (i, i) = l raw (j, i, i) l node (i) =[ j=1 n l n (i, j)+l n (j, i)] l n (i, i) j=1 2) Average ICR of distributed controller r(a) = r 1 + r r n (4) n 4. Average response time The average response time refers to the average time from which the forwarding device sends a request to the time at which it receives indicators. Owing to differences in infrastructure and storage, these architectures have a huge difference in response time; we adopt T rtt as a roundtrip delay of network communications between any two devices in a stable network. T res (A) is calculated below: T res (A) =r(a) T rtt +(1 r(a)) (2T rtt + T lp ) (5) 1) Average response time of SDS architecture T res (SDS)=r(SDS) T rtt +(1 r(sds)) (2T rtt + T lp ) 2) Average response time of CS architecture T res (CS)=T rtt + T lp 3) Average response time of CIG architecture T res (CIG)=r(CIG) T rtt +(1 r(cig)) (2T rtt + T lp ) If many requests cannot be directly handled by the controller instance in a SDS architecture, the controller instances frequently access the remote database. This results in reduced efficiency of the distributed controller. When a network is huge and continues to enlarge, the response time of the remote database will continue to grow. In summary, the SDS architecture saves storage resources and reduces synchronization overhead, but it cannot easily meet the needs of large-scale networks in terms of average response time. CS architecture networks, although they respond quickly, are unlikely to be the best solution because of their huge cost in terms of resources. CIG is a compromise approach between SDS and CS. 5. The total resource overhead assessment The system must evaluate the efficiency of the controller. The total resource overhead assessment is η = α C M (A)+β T res (A)+μ C SYN (A) (6) We normalize all resources before the weighted summation to adjust the impact of each resource on the controller. We believe that there is a certain proportional relationship between the storage and communication overhead. C SYN (A) =δ C M (A) Thus, the formula can be simplified as follows: η = α C M (A)+β T res (A) The experiments in this paper adjust the groups to affect ICR; in the course of the grouping, we coordinate both storage overhead and average response time to reduce the total resource overhead. The application range of SDN is far beyond that of the data center, so the weights of each resource depend on the actual environment. IV. Autonomous Domain Correlation Analysis Before controller instances are added to a certain group, calculated communications between a given controller instance and another one within the group are needed. The rate at which requests are received by controller instance x i can be calculated in the network view of its autonomous region but does not reflect that of the most related group. Therefore, when selecting a suitable group, the controller requires an extra operation to calculate the correlations among autonomous regions. The required variables are displayed in Table 2. Table 2. Autonomous domain correlation parameters Parameter Description The correlation between controller instance x i and R θ (i, j) group j. The correlation between controller instances x i and R ω(i, j) x j.

5 Autonomous Domain Correlation-Based Cross-domain Network View Caching Method for SDN Distributed Controller 1131 This article uses only the number of packets to calculate the values of l n (i, j) inl n. l n (i, j) cannotexplain why the autonomous domains of two controller instances are contiguous, so we must pretreat L n. For example, in Fig.4, there are six autonomous regions from AD 1 to AD 6 managed by six controller instances from x 1 to x 6,respectively. Suppose that there are data flows from AD 4 to AD 3 with a huge number of packets counted in L n matrix; the system sorts x 4 and x 3 intoagroup.ifthe system stops the grouping algorithm, this group contains only x 3 and x 4, and its synchronized view is split apart. Thus, we must use the data of L n to calculate a matrix that contains only the statistics of adjacent autonomous domains. Fig. 4. Autonomous domains To avoid this situation, this study uses the original data l raw (i, j, k) to obtain the matrix that contains only communications between neighborhoods. l raw (i, j, k) refers to data statistics from one autonomous domain of x j to the other of x k monitored by controller instance x i.to find the noncontiguous autonomous domains, we find the controller instance receiving requests whose source and destination IP do not belong to the autonomous domain of this controller instance. This system must traverse all l raw (i, j, k) if one of the elements satisfies the following conditions: A. l raw (i, j, k) Null;B.j / g i and k / g i Then,l n (j, k) =l n (k, j) =0 After ensure that L n elements are based on adjacent autonomous domains, we began computing autonomous domain correlations. 1) The correlation between controller instances x i and x j R ω (i, j) = l n (i, j) n n l n (o, p) o=1 p=1 p o 2) The correlation between controller instance x i and group group j l n (i, k) x k group j R θ (i, j) = [l node (i) l n (i, i)] group j R θ (i, j) is divided by group j to prevent a group from excessively enlarging; this group receives all instances, and the algorithm becomes a vicious cycle. We use the average correlation value among the group controller instances and x i to represent the correlation between controller instance x i and group group j. V. Controller Instance Grouping Algorithm The network view management process divides controller instances into several groups based on autonomous domain correlations and then implement network view synchronization within each group. Correlations among autonomous domains change with the variation of communication. Therefore, a slice of the network view dynamically follows the changes in the network, and the controller ultimately achieves a balance between the various resources and service requirements. To perform this work, we first study the network conditions for using the network view caching method; we then propose a grouping algorithm to divide controller instances into several groups. 1. Algorithm conditions The view caching method presented in this article cannot improve the efficiency of a system in all cases; sufficient conditions must first be met to perform this grouping operation. This article summarizes two important conditions. 1) If the value of ICR is very high, the majority of current communications are inner autonomous domain traffic, so there is no need to store information on other subnets because the controller instance processes most requests with local data. Thus, the first condition is that r(a) be below a certain threshold, whose value may be preset by the system. 2) If communication statistics among controller instances are uniformly distributed in a matrix, the merger between any two controller instances has little effect on the total overhead of the controller. We calculate the entropy of L n before using the grouping algorithm. 2. Controller instance grouping algorithm Assume that the whole collaborative controller has n controller instances. Our grouping algorithm is a greedy algorithm that operates the controller instance with the largest value of L n in each loop. We then determine which existing group is most closely associated with this controller instance. Finally, if the merger operation can re-

6 1132 Chinese Journal of Electronics 2016 duce system overhead, the system inserts this controller instance into this group. Algorithm Controller instance grouping Input: X controller instance set L n N-order matrix Output: Group a collection of groups. 1: X all x i; 2: Group=NULL 3: While (X is not NULL) do 4: Select x i with highest l node (i) 5: if group is equal to NULL 6: then inserts a group i composed of x i into Group, remove x i from X 7: else 8: for each group j in Group do 9: compute R θ (i, j) between x i and group j 10: find the largest R θ (i, k) inexistingr θ (i, j) 11: calculate the total cost of controller η after x i joins group k 12: if η η > 0 13: then insert x i into group k 14: η = η 15: else 16: insert a group i composed of x i into Group, remove x i from X 17: cache network views of each group to controller instances The initial state of this algorithm is the SDS model. The algorithm uses two indicators to determine whether to insert a controller instance into an existing group: correlation among controller instances and the total cost of the distributed controller. During the selection of the controller instance, we use correlations between the controller instance and the group because its calculation is much less costly than the total cost. VI. Experiment and Discussion We first measure the relational views between storage overhead and the variations of the network, using a DELL OPTIPLEX 3010 computer (64-bit Intel Core i clocked at 3.2GHz, 8GB of memory) to run the ONOS controller while measuring the storage overhead of network views. Mininet was adopted to simulate some typical topologies. We then used an open-source MCFP dataset to analyze network traffic characteristics and calculate L n. 1. Storage overhead measurement Network views that exist as graphs in distributed controllers include such data as nodes, links, flow tables, group tables, and meter tables maintained by the controller; these data have key impacts on the efficiency of each application. Currently, the flow table record length generally varies from 50Kb to 200Kb, and specific storage overhead and processing speed are varied in accordance with different servers. Therefore, we record the number (sum) of network view entries as storage overhead to discuss the experiment with a relatively stable parameter.to ensure the neutrality of the results, we use built-in ONOS algorithms to process requests from network devices. 2. Communication statistics MCFP datasets are open network traffic data collected by Czech Technical University. We measure communication statistics within each pair of IP addresses and then determine correlations between controller instances. We extract 100,000 packets from the MCFP dataset and compute the quantities of packets based on source IP and destination IP in the match field. We intend to use 8 controller instances from x 1 to x 8 to manage the entire network. We use the mapping of controller instances and hosts to transform packet statistics into L n.table3shows the experimental data. Each row changes the controller instance of destination autonomous domain, and each column changes the controller instance of source autonomous domain. Table 3. L n of MCFP fragment n =8 L n x 1 x 2 x 3 x 4 x 5 x 6 x 7 x 8 x x x x x x x x Algorithm evaluation In this section, we validate the efficiency of the grouping algorithm(shown in Table 4). Table 4. Grouping result Cycles x i l node (i) highest correlation Group status [7] [7,2] [7,2],[4] [7,2],[4],[5] [7,2],[4],[5],[6] [7,2][4,8],[5],[6] [7,2],[4,8],[5],[6],[1] [7,2][4,8],[5],[6],[1],[3] In the grouping process, there are two controller instances added to groups after a judgment of the total system cost (x 2 and x 8 ). Trends in total costs of SDS, CS, and CIG are shown in Fig.5. We reduce the response time at the slight expense storage overhead. The Cost evaluation values (CEV) of resources are shown in Table 5.

7 Autonomous Domain Correlation-Based Cross-domain Network View Caching Method for SDN Distributed Controller 1133 Fig. 5. Total cost Table 5. Changes of each overhead in process CEV SDS CS CIG Storage Delay The entire process increases storage overhead by 5.6% while reducing response time overhead by 12.97%. Our study improves the overall performance in the distributed controller. VII. Conclusion Our proposal uses statistics and autonomous domain correlations in the SDN distributed controllers and then determines the imbalanced network communication. Experimental results show that our method has achieved remarkable efficiency when considering a variety of resources, and the rational utilization of network resources is realized to improve the overall controller performance.we did not present a dynamic method for calculating proper weights. This will be the focus of future research on network view caching. References [1] S. Shenker, M. Casado, T. Koponen and N. McKeown, The future of networking, and the past of protocols, Open Networking Summit, Vol.20, [2] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh, et al., B4: Experience with a globally-deployed software defined WAN, ACM SIGCOMM Computer Communication Review, Vol.43, No.4, pp.3 14, [3] N. Mckeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, et al., OpenFlow: Enabling innovation in campus networks, Acm Sigcomm Computer Communication Review, Vol.38, No.2, pp.69 74, [4] A. Tootoonchian and Y. Ganjali, HyperFlow: A distributed control plane for OpenFlow, Proceedings of the 2010 Internet Network Management Conference on Research on Enterprise Networking, pp.3, [5] K. Phemius, M. Bouet and J. Leguay, Disco: Distributed SDN controllers in a multi-domain environment, Network Operations and Management Symposium (NOMS), IEEE, Krakow, Poland, pp.1 2, [6] P. Berde, M. Gerola, J. Hart, Y. Higuchi, M. Kobayashi, T. Koide, et al., ONOS: Towards an open, distributed SDN OS, Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, Chicago, IL, America, pp.1 6, [7] P. Lin, J. Bi, S. Wolff, Y. Wang, A. Xu, Z. Chen, et al., A west-east bridge based SDN inter-domain testbed, IEEE Communications Magazine, Vol.53, No.2, pp , [8] M. Jarschel, T. Zinner, T. Hoßfeld, P. Tran-Gia and W. Kellerer, Interfaces, attributes, and use cases: A compass for SDN, IEEE Communications Magazine, Vol.52, No.6, pp , [9] P. Lin, J. Bi and Y. Wang, East-West Bridge for SDN Network Peering, Communications in Computer and Information Science, Vol.401, pp , [10] S. Hassas Yeganeh and Y. Ganjali, Kandoo: A framework for efficient and scalable offloading of control applications, Proceedings of the First Workshop on Hot Topics in Software Defined Networks, Helsinki, Finland, pp.19 24, [11] X. Shao, R. Wang, H. Huang and L. Sun, Load balanced coding aware multipath routing for wireless mesh networks, Chinese Journal of Electronics, Vol.24, pp.8 12, [12] X. Li, H. Li, K. Yang and Q. Liu, An optimization forwarding range routing protocol for VANET in city environments, Chinese Journal of Electronics, Vol.23, No.1, pp , [13] X. Yang, A. Shen, J. Yang, J. Ye and J. Xu, Artificial neural network based trilogic SVM control in current source rectifier, Chinese Journal of Electronics, Vol.23, pp , [14] D. Kreutz, F.M. Ramos, P. Esteves Verissimo, C. Esteve Rothenberg, S. Azodolmolky and S. Uhlig, Software-defined networking: A comprehensive survey, Proceedings of the IEEE, Vol.103, No.1, pp.14 76, [15] A. Krishnamurthy, S.P. Chandrabose, and A. Gember- Jacobson, Pratyaastha: An efficient elastic distributed sdn control plane, Proceedings of the Third Workshop on Hot Topics in Software Defined Networking, Chicago, IL, America, pp , [16] I. Schafer and M. Felser, Topology discovery in PROFINET, 2007 IEEE Conference on Emerging Technologies and Factory Automation (EFTA 2007), Patras, Greece, pp , [17] D. Erickson, The beacon openflow controller, Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking, Hong Kong, China, pp.13 18, FU Tao is a Ph.D. candidate at Jilin University, advised by Liang Hu. His research interests include Software Defined Networks and Cloud Computing. ( futao13@mails.jlu.edu.cn) CHE Xilong (corresponding author) was born in Received the M.S. and Ph.D. degrees in Computer Science from Jilin University, in 2006 and 2009 respectively. Currently, He is an associate professorandamastersupervisoratthecollege of Computer Science and Technology, Jilin University, China. His current research areas are Parallel & Distributed Computing, Machine Learning, and related applications. He is a member of the ACM/IEEE. ( chexilong@jlu.edu.cn)