[Docs] [txt|pdf] [Tracker] [Email] [Nits]



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]


Html markup produced by rfcmarkup 1.122, available from https://tools.ietf.org/tools/rfcmarkup/