Network Working Group J. Zhao Internet Draft Fudan University Intended status: Informational Y. Xu Expires: December 2017 BNC June 16, 2017 A Model for Building SDN Control Plane with Multiple Controllers draft-zhao-opsawg-model-sdn-multi-controller-00 Abstract This document describes a reference model for building SDN control plane with multiple controllers. It defines the key components in the model and introduces an effective mechanism to balance the load between controllers. The design also considers the tradeoff between scalability and performance. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 16, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Zhao et al. Expires December 16, 2017 [Page 1] Internet-Draft Model for Multi-Controller SDN Control Plane June 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction ................................................ 2 2. Terminology ................................................. 3 3. Multi-server Controller Framework ........................... 3 4. Switch-controller Interaction................................ 4 5. Design Issues ............................................... 5 5.1. Load balance ........................................... 5 5.2. Traffic Mapping......................................... 5 6. Security Considerations...................................... 6 7. IANA Considerations ......................................... 6 8. References .................................................. 6 8.1. Normative References.................................... 6 8.2. Informative References.................................. 6 1. Introduction The centralized design of control plane in software defined networking(SDN) brings the benefit of network programmability. The design allows a logically centralized controller to control a number of network switches and thus enables more flexible control with global information. However, the centralized design also leads to scalability concerns. With the increase in flow number and network size, controllers will experience performance bottleneck. Therefore, it is critical to scale up the performance of controller for real- world SDN deployment. The document defines a reference model and associated interconnection mechanism for building a controller using server clusters. The model integrates commodity servers and OpenFlow switches into a powerful logically centralized controller. On one hand, a number of OpenFlow switches are used to serve as a highly scalable front-end switch group, which can handle high-throughput data traffic. On the other hand, a number of commodity servers are deployed to serve as the controller cluster, which leverages the parallelism of cluster to balance the control plane load. Each server in the cluster thus deals with partial load from the control plane by a load balancer. Zhao et al. Expires December 16, 2017 [Page 2] Internet-Draft Model for Multi-Controller SDN Control Plane June 2017 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. SDN Software Defined Networking 3. Multi-server Controller Framework With the increase in network scale and traffic flow, the control plane load is expected to increase significantly. In order to make the controller scalable, the design principle is to balance the control plane load across multiple OpenFlow controllers. A cluster of loosely or tightly connected servers that work together, can be regarded as one logically single controller. Each controller in the cluster deals with partial load from the control plane by a load balancer [2]. The multi-server controller reference model, as shown in figure 1,identifies the components that a controller cluster includes. Being an integrated architecture, the model takes the advantage of commodity server cluster and works as one logically centralized controller. According to the need for scaling up the performance of controller, the multi-server controller reference architecture includes: o Server Cluster A pool of OpenFlow controller units (commodity servers) are organized to share the controlling overhead of the logical controller. o Switch Group A set of OpenFlow switches are employed at the front-end switch group, which servers as the I/O interface between the controller cluster and the network being managed. o Load balancer To schedule the internal resources of the integrated controller, we introduce an load balancer. It manages both the Switch Group and the Controller Cluster. The load balancer actively monitors the CPU and I/O resources of the servers in Controller Cluster and the switches in Switch Group. Zhao et al. Expires December 16, 2017 [Page 3] Internet-Draft Model for Multi-Controller SDN Control Plane June 2017 o Global View Though the servers in Controller Cluster work independently from each other, they share a common view of the control information, such as network topology, routing information, and the link status of the OpenFlow network. To synchronize the data among these servers, we introduce a network information database. Each server needs to report the latest control information to this database. +------------------------------------------------------------+ | +-----------+ +------------+ +------------+ | | | | | | | | | | | Server 1 | | Server 2 | ... | Server n | | | | | | | | | | | +-----------+ +------------+ +------------+ | | ^ ^ ^ | | | | | | | V V V | |------------------------------------------------------------| | | | o---------------o +------------+ o----------------o | | | Global View | |Switch Group| | Load Balancer | | | o---------------o +------------+ o----------------o | | | |------------------------------------------------------------| | ^ | | | | | V | | +--------------+ | | |Client switch | | | | | | | +--------------+ | +------------------------------------------------------------+ Figure 1 Controller cluster framework The model takes the advantage of commodity PC server cluster and works a fully functional OpenFlow controller with high scalability. It can serve a number of client switches for a large-scale network. 4. Switch-controller Interaction The typical interaction between the client switch and the multi- server controller is handling the packet-in message. The procedure works as follows. Zhao et al. Expires December 16, 2017 [Page 4] Internet-Draft Model for Multi-Controller SDN Control Plane June 2017 1. According to the resource usage and the pre-defined resource allocation policy, the load balancer will first select a proper controller and redirect the packet to the controller. 2. When the packet reaches the given controller server in the cluster through switch group, the controller decodes the packet, and then processes it. The controller also needs to update the global view database accordingly. 3. If some feedback is generated, the controller will send it to the corresponding client switch. 5. Design Issues 5.1. Load balance OpenFlow defines three roles for controller: master, slave and equal. Master and slave are usually used for fail-over or fast recovery. In the multi-server architecture design, controllers are configured to share the workload by setting the role as equal. With the role of equal, the controller can receive all the asynchronous messages from switches and send commands to switches. The objective of a load balancer for OpenFlow network consists of the following aspects: 1. Balancing CPU workloads: The CPU-intensive applications, such as maintaining topology, querying the network configurations, and computing the minimum spanning tree or shortest path, may consume a large amount of CPU resources. High utilization can be achieved by allocating these CPU-intensive applications to a controller which has the lowest CPU usage. 2. Balancing I/O workloads: A controller generally involves periodical operations such as maintaining connection between controllers and switches, sending and receiving control commands for modifying switches. Though simple, these frequent I/O intensive operations will also result in a large amount of I/O resource consumption. In order to reduce the load on a certain controller, these I/O-intensive operations can be shared between different controllers by using the load-balancing structure. 5.2. Traffic Mapping In the original OpenFlow design, each OpenFlow switch is connected to one single OpenFlow controller. In our design, cCluster consists of a number of controllers for scalability consideration. If a new Zhao et al. Expires December 16, 2017 [Page 5] Internet-Draft Model for Multi-Controller SDN Control Plane June 2017 controller is added to the cluster, the load from client switches must be able to redirected to the new one for load balancing. However, existing OpenFlow specifications do not support such feature. Therefore, a middle layer with the capability of flexible traffic mapping is needed in order to enable redirecting traffic from any OpenFlow switch to any controller in the cluster. In the reference model, the middle layer is actually an internal SDN consists of two parts: Switch Group, and load balancer as shown in Figure 1. Switch group interconnects the controller cluster and the external client switches. With OpenFlow, the load balancer can measure the load of each OpenFlow controller, and then change the connection status adaptively in the middle layer. 6. Security Considerations This document discusses a reference model for implementing SDN controller using multiple servers. The solution discussed may have security implications, such as control flow saturation attacks, unauthorized access to the global view. Framework described in this document is limited to the architecture design. Security considerations regarding specific attack can be addressed in their respective domains. 7. IANA Considerations This memo does not have any IANA considerations. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [2] Qiu, K., Tu, R., Huang S., Zhao J., and Wang X., cCluster: A Highly Scalable and Elastic OpenFlow Control Plane In Proc. of IEEE/ACM IWQoS, Portland, OR, USA, Jun., 2015. Zhao et al. Expires December 16, 2017 [Page 6] Internet-Draft Model for Multi-Controller SDN Control Plane June 2017 Authors' Addresses Jin Zhao Fudan University 825 Zhangheng Rd., Shanghai 201203, China Email: jzhao@fudan.edu.cn Yanwei Xu Shanghai Engineering Research Center for Broadband Networks and Applications (BNC) 150 Honggu Rd., Shanghai 200336, China Email: ywxu@bnc.org.cn Zhao et al. Expires December 16, 2017 [Page 7]