Autonomicity Design in OpenFlow Based Software Defined Networking

GC'12 Workshop: The 4th IEEE International Workshop on Management of Emerging Networks and Services Autonomicity Design in OpenFlow Based Software Defined Networking WANG Wendong, Yannan HU, Xirong QUE, GONG Xiangyang State Key Laboratory of Networking and Switching Technology Beijing University of Posts and Telecommunication Beijing, China {wdwang, huyannan, rongqx, xygong }@bupt.edu.cn Abstract Software Defined Networking (SDN) is a new area in network management. It is understood as using software to improve the network capabilities and intelligence. Autonomicity is one of proposed technologies, which also can improve network management capabilities. A scheme of the combination of OpenFlow based SDN and Autonomicity is proposed in this paper to introduce self-* attributes into OpenFlow Based SDN so that the network could be better controlled and operated efficiently. Keywords OpenFlow, Software Defined Networking, Autonomicity, self-management I. INTRODUCTION With the increasing variety of applications or services for a huge number of users, Internet has already become a kind of global communication infrastructure. But, the current Internet is still facing great challenges in network configuration, control and management issues. Research on Internet application/ service/ network control and management is one of the focuses in recent years. Lots of research projects have been initiated in this area. Software Defined Networking (SDN) [1] is an emerging technology for network architecture innovation. It decouples the network control and data forwarding. SDN is understood as using software to enhance the intelligence and capabilities of network routers and switches so that the network could be better controlled and operated more efficiently and with advanced customizability of network control and forwarding behaviors. Autonomic communication [2] is one of the research fields in future network control and management. Self-Awareness, Self-Configuration, Self-Protection, Self-Healing, Self- Optimization and Self-Organization are a series of autonomic attributes of Autonomicity. The objective of introducing these autonomic attributes into network is to decrease the complexity of network control and management in heterogeneous network environments, and to minimize the burden of manual operation. By introducing the Self-Awareness, Self-Configuration, This work was supported in part by the National High-tech Research and Development Program (863 Program) of China under Grant No. 2011AA01A101, National Basic Research Program of China (973 Program) under Grant No. 2009CB320504, National Natural Science Foundation of China under Grant No. 61271041 and Fundamental Research Funds for the Central Universities. Self-Optimization and Self-Organization attributes into OpenFlow Based SDN architecture, Programmable capability of the SDN could be enhanced to an environment aware programmable capability. This enhanced programmable capability also has other self-* attributes. For example, according to specified applications characteristics, Autonomic OpenFlow Based SDN could build a specified application network by self-configuration in node level and selforganization in network level. It can also improve its performance by self-optimization through the self-awareness attribute continuously. SDN, which decouples control and forwarding capabilities, has improved its intelligence in network control so that the operation and management functions of SDN could be more efficiently. The rest of the paper is constructed as follows. Section II introduces the related works and background technologies about SDN, OpenFlow and autonomicity. Section III describes the requirements of a kind of Autonomic SDN model. Section IV presents the details of the Autonomic SDN model design. Section V concludes the paper work. II. RELATED WORK Currently, most network switches and routers have remained their own intellectual proprietary right of the manufacturers. Both hardware and software of them are controlled and locked by the manufacturing companies. But network scientists seek to change this disposition, and aim to make the control remotely accessible and modifiable via thirdparty software by using the open protocols. SDN is a novel network architecture/approach which enables innovations by Figure 1. Software Defined Networking 978-1-4673-4941-3/12/$31.00 2012 IEEE 818

Figure 2. OpenFlow Architecture Match Field Priority Counters Timeouts Instructions Cookie Per Table / Per Flow / Per Port / Per Queue Actions Pipeline Processing 1. output (Port & Table) 2. Drop 3. Group 4. Enqueue 5. Push / Pop tag 6.... Ingress Metadata src dst type ID Priority Label TC Prot MAC MAC Eth VLAN VLAN MPLS MPLS IP IP IP src IP dst Sport Dport... Port ToS Figure 3. Flow Table processing is included in instructions associated with each flow entry. Actions may contain packet forwarding, packet modification and group table processing procedures. Pipeline processing instructions allow packets to be sent to subsequent tables for further processing and allow metadata information to be communicated between tables. In OpenFlow-based SDN, the control and data forwarding functions are decoupled. The underlying network devices are abstracted from the upper layer control and applications. Network control and management function in OpenFlow controller could be logically centralized or distributed and independent with the underlying network. So it may provide high performance, flexible management and granular traffic control for multiple vendors network devices. The MAPE model [4] is an abstraction of an autonomic system defined by IBM. The Autonomic Manager and the Managed Element/Resource entities are designed in this model. The monitor, analyze, plan and execute functions form a control loop in Autonomic Manager, and the knowledge being the central is used to drive the control loop. The knowledge related to all the pieces connected by the general knowledge space is indicated in Fig. 4. For example, monitoring information supplied by the sensor part of the Managed Element/Resource constitute knowledge. Similarly, the aspects of how to analyze the monitoring information, the plan of actions to be executed as a result, how and when to execute the actions on the Managed Element all amount to knowledge. Knowledge also includes information in the cognitive aspects of the Autonomic Manager. network researchers, operators, application/service providers, and third parties as well as by network equipment vendors [3]. The key characteristics of SDN are (as shown in Fig. 1): (1) Data plane and control plane are defined; data control and forwarding are separated; (2) the network OS and open API/protocol are defined between the two planes; (3) a logically centralized control entity with an open API/protocol for network control/management is defined; (4) and functions of network slicing and virtualization are designed to support network experimentation. OpenFlow is an instance of forwarding abstraction of SDN. The OpenFlow switch, controller and OpenFlow protocol are the main components of OpenFlow (as shown in Fig. 2). A secure channel between OpenFlow switch and controller is used to perform management and control information communication via the OpenFlow protocol. One or more flow tables and a group table in the OpenFlow switch are used to perform packets lookup and forwarding (as shown in Fig. 3). Each flow table in the OpenFlow switch contains a set of flow entries; each flow entry consists of match fields, priority, counters, and a set of instructions to apply to matching packets. These flow entries in flow tables could be added, deleted and updated by the controller via OpenFlow protocol. In OpenFlow switch, matching begins from the first flow table and may continue to follow flow tables. Flow entries match packets according to priority order in corresponding flow table. The instructions associated with the specific flow entry would be executed if a matching entry is found. Actions or pipeline Figure 4. IBM s MAPE generic model of an autonomic system [8] Generic Autonomic Network Architecture (GANA) [5] is another abstract model proposed by EU PF7 EFIPSANS project (as shown in Fig. 5) [6]. The GANA control loop is derived from IBM-MAPE model for autonomic networking specifically. The model illustrates the possible distributed nature of the information suppliers that supply a Decision Element (DE), with information (knowledge) that is used to manage the associated Managed Element(s)/Resource(s). In this model, the concept of a Decision Element is adopted as the autonomic management element, which is similar to the role of an Autonomic Manager in the MAPE model. The concept of a 819

Figure 5. Abstract model of Generic Autonomic Network Architecture [5] Managed Entity (ME) is also adopted to mean a Managed Resource or a Managed Automated Task, instead of a Managed Element, in order to avoid the confusion that comes when one begins to think of an element as only meaning a physical network element. It also illustrates the fact that the behaviors or actions taken by the DE do not all necessarily have to do with triggering some behaviors or enforcing a policy on the Managed Resource(s), but some of the behaviors executed by the DE may have to do with communication between the DE and other entities, e.g. other DEs in the system or network. This is indicated by the extended span of the arrow Downward Information flow or Horizontal information flow to other DEs. For example, the DE may need to self-describe and selfadvertise to other DEs in order to be discovered or to discover other DE, in order to communicate or get views knowledge known by the DE. It is also illustrated on the figure that the nature of the Managed Entity(s) may be of a physical entity, or may have the nature of an automated task implemented by either a system function or a networking function which is implemented by a single protocol, or diverse protocols that may employ diverse algorithmic schemes or policies. III. REQUIREMENTS FOR AUTONOMIC SDN DESIGN Traditional network faces increasing difficulty to meet the requirements of current services, users and carriers. The explosion of media contents and mobile devices, widely deployment of cloud services and resource virtualization are some important trends driving the network researchers to think more about the new Internet network architecture and routing/forwarding as well as management technologies. Current Internet is also facing the great challenges in following points: (1) Network management capabilities still are quite simple, lacking of node/network configuration, control and management functions; (2) QoS support for real time application in large scale internet still need to improve; (3) Increasing network complexity leads to internet technologies stasis; (4) The scalability of internet and network equipments are strongly vendor dependence. In order to evaluate the technical possibility of combination of autonomicity and SDN, we are starting to initiate a project to design a novel autonomic OpenFlow Based SDN model. We raise the following points as the requirements of our project: (1) Autonomicity The management complexity of the Internet caused by its rapid growth becomes a major problem that limits its usability in the future. The ultimate aim of introducing autonomicity is to decrease the complexity of network control and management and to minimize the burden of manual operation. (2) Programmability To build a new network with various features, it is required that the new network should be designed like a software. SDN is programmable and decouples the control and data forwarding. It is also understood that the network could be better controlled and operated more efficiently by using software. OpenFlow [7] is an emerging technology allowing for network programmability on its control plane. (3) Virtualization Network virtualization can logically separate a single physical network infrastructure into multiple logical virtual networks. Those virtual networks can be used to support multiple different kinds of network architecture. Each customized virtual network could be used to support an application-specific service. (4) Packets matching extension Although, it is impossible for early version OpenFlow to deeply analyze the packets payload by using its fixed match fields, the direction to create a more flexible match mechanism is already raised by the OpenFlow community. For example, the latest OpenFlow specification [8] introduces extensible match fields by employing a TLV structure. This improvement allows more flexibility for the switch and forwarding treatment. IV. AUTONOMIC SDN FUNCTION DESIGN A. Autonomic OpenFlow-based SDN Model The proposed Autonomic OpenFlow-based SDN model is illustrated in Fig. 6. This Model has the following layers and planes: Figure 6. Autonomic OpenFlow Based SDN Model 820

Physical network infrastructure (Physical layer or Data plane): It is the data plane of the Autonomic OpenFlow based SDN Model that includes OpenFlow switches, routers, other network elements (such as some types of middle box) and application servers and clients (Hosts). The physical network infrastructure achieves the basic connectivity of the networks, and it is the bearer network of all kind of services and applications. It also provides some secure channel to support the control info communication between management plane and data plane. Virtual networks layer: Physical resources, such as switches and servers at data plane are virtualized and consist of several different kinds of virtual networks to support specified services and applications. These virtual networks are belonging to data plane but were virtualized in different network topology layers for different specified services and applications. Virtual network infrastructure is realized by gathering appropriate virtual resources from data plane. A new control and management plane is created to control and manage those virtual resources. In other words, a virtual network is defined by a set of virtual resources and relevant control and management programs or functions which are running on the management plane. This management plane could be thought as an OpenFlow controller. In our design model, these virtual networks can support different network architectures and different services, and even the relevant control and management function could also be different, which are customized according to the specified application/service carried by different virtual networks. For example, different control and management functions may support different addressing and routing system (e.g. IP address in Internet and E.164 in telecommunication network). Virtual network resources control layer: By using a kind of universal description of the virtual resources, each virtual network provides a universal virtual resources abstraction to the virtual network resources control layer. The control logic in the virtual network resource control layer is responsible for detecting, maintaining and allocating the virtual resources, and giving the virtual network resource control logic programmatic access to the virtual network. These virtual network resource control logic, such as path creation, data forwarding roles, traffic engineering, etc. determine the designed virtual network behaviors. Note that, since each virtual network typically carries different services, the control logic of different virtual network resources control planes could be different. Service control layer: When the specific services or applications are deployed on a virtual network, the dedicated service control logic would be constructed automatically to control and manage the service deployment according to its specific requirements. Management Plane: There are two types of management plane in our Autonomic OpenFlow-Based SDN model: one is called Generic Network Management plane (GNM plane) and the other is called Virtual Network Management plane (VNM sub-plane). The GNM is a generic autonomic manager (or called Decision Element (DE)) to manage all VNMs, each VNM could be considered as a Managed Entity (ME) in GNM plane. Those VNM MEs together with GNM DE consist of an autonomic system on GNM plane. GNM function is responsible for the management of all VNMs, It also performs the function of physical resource configuration and physical network organization. Working with all VNMs, GNM could implement several self-* attributes, such as self-configuration, self-organization and selfoptimization. VNM function is responsible for the management of virtual networks, virtual resources and associated services or applications. VNM is defined as an autonomic manager (or DE) for virtual networks. The Virtual networks layer, Virtual network resources control layer and service layer could be considered as its MEs. The VNM (in service infrastructure environment) together with the virtual networks layer, virtual network resources control layer and service layer consists of another autonomic system on VNM sub-plane. The self-* attributes, such as self-awareness, self-configuration, selforganization and self-optimization could also be implemented in the service infrastructure environment. The function design of VNM sub-plane is addressed in section B and the function design of GNM plane is described in section C. B. Autonomic Management and Control Functions Design Autonomicity in our Autonomic OpenFlow-based SDN Model, an enabler of advanced and enriched self-manageability of SDN, is realized through introducing a number of control loops into management plane. Each control loop consists of the following four basic components: monitoring entity, analyzing entity, planning entity and executing entity. The monitoring entity is responsible for collecting and organizing context from the required managed sources. Then the analyzing entity would analyze the context and produce sets of control policies. Then, planning entity would plan several possible operations according to collected context and proposed policies. The control loops are typically policy based. Once a certain condition is satisfied, an action could be running by executing entity at last. Management Plane Analyzing Planning Analyzing Planning Analyzing Planning Monitoring Executing Monitoring Executing Monitoring Executing Service Control Plane Network Resource Control Plane Virtual Network Figure 7. Automatic management and control within virtual network 821

There are three control loops residing in the corresponding Virtual Network Management (VNM) plane, each of which is associated with one of the three layers in a virtual network: virtual network layer, virtual network resources control layer and service layer. Figure 7 illustrates the concept of autonomic management and control. In general, these control loops reflect the self-* attributes at different levels: virtual node level, virtual network level, and service level. The information collected by the different monitoring entity could be different. Meanwhile, inter-control loop information monitoring is also necessary. For example, the Monitoring entity in a control loop on the service level monitors service-relevant information, such as service type, service parameters, service QoS requirements, and service performance etc. the Monitoring entity in a control loop on the virtual network level monitors information such as virtual network topology, traffic load, available bandwidth, failure information etc. as well as the commands generated in the service level control loop; the node level monitoring entity collects information such the size of flow tables, CPU utilization and queue length, and node configuration command sent from the network level control loop et.al,. The analyzing entity uses various types of contexts (e.g. current and historical, short-term and long-term, global and local info) to build models which capture changes in the network environment, and determine if anything else needs to be done. The output from analyzing entity could be utilized by the planning entity to make dynamic decisions that guide the self-reconfiguration of the network. The dynamic network reconfiguration is also policy-based. The network management policy can be viewed as a set of rules, each of which is consisted of a set of conditions and actions. Once a certain condition is satisfied, relevant actions would be triggered. Policy-based network management, a systematic network management system, emphasizes that the self-* attributes should be inherent, and the virtual resources utilization within a virtual network can thus be optimized by themselves. C. Context-aware Virtual Network Resource Allocation Traditionally, each virtual network in SDN is assigned with a static share of the network resources, and the bandwidth of each substrate link could be ensured by resources isolation. While it may be sufficient for the network experiments, static resource allocation is usually inefficient for real services deployment. For example, in a congested virtual network, service would be experienced a high end-to-end delay, even if other virtual networks are light loaded. Generic Network Management (GNM) plane function is proposed to manage various virtual networks with many kinds of resources allocation requirements. This function can fulfill the demands from different virtual networks. In this way, the resources of underlay physical network infrastructure are sliced according to the requirement of each service or application. The objective of GNM plane is to realize context awareness and optimal resource configuration. Figure 8 shows the concept of context-aware virtual network resources allocation. The monitor entity in the GNM plane monitors the environment of physical and virtual networks (e.g. the state of the networks and available resources), as well as the resources demanded from the services running on the virtual networks. Based on the Monitor Analyze Plan Execute Management Plane 1 Management Plane 2 Physical Network Management Plane n Service Control Plane n Service Control Resource Plane 2 Control Plane n Service Control Plane Resource 1 Virtual Network Control Plane 2 n Resource Control Plane 1 Virtual Network 2 Virtual Network 1 Figure 8. Context-aware virtual network resource allocation objectives of GNM plane, the analyze entity and plan entity are utilized to monitor information of the services and to determine how to adjust the network configuration dynamically through the appropriate learning and reasoning mechanisms. Finally, the execute entity can reconfigure the whole network according to the system knowledge. So virtual resources management function can be achieved by the network itself through the autonomic attributes, such as self-configuration, selforganization and self-optimization of the inter-virtual-network resources. This could maximize the utility of the network resources. D. Network Virtualization based on Extensible Packet Matching and Pipeline Processing A full virtualization mechanism is needed in order to implement the multiple virtual networks in one underlying physical network infrastructure. According to the specification of OpenFlow version 1.3, the extensible packet matching and the pipeline feature could be used to provide more flexible network virtualization mechanism. In order to support multiple forwarding paradigms, all flow tables should be designed to support the extensible packet matching mechanism. And the OpenFlow pipeline is also divided into multiple sub-pipelines. The number of subpipelines is equivalent to the number of virtual networks that we designed for multiple forwarding paradigms. As we know, pipeline processing always starts at the first flow table: the packet is first matched against entries of flow table 0.Other flow tables will be used depending on the matching results in Table 0 Standard+ Extension Action Table 1 IP Action Table 2 Lable Action Table 3 Name Action Table 4 Tos Action Table 5 Action Traffic Class Virtual Network 1 Virtual Network 2 Virtual Network 3 Figure 9. Network Virtualization based on extensible packet matching and pipeline processing 822

the first table. Thus, in our approach, the flow table 0 is used as a de-multiplexer, which dispatches packets and flows to different sub-pipelines. Figure 9 illustrates a specific case of the proposed mechanism where the switch carries flows of three virtual networks. As shown in the figure 9, different kinds of forwarding approaches can be used in different virtual networks, for example, the traditional IP-based packets routing and forwarding are used on virtual network 1, while the virtual network 2 and 3 are used to support label-based switch/routing and named-based routing/forwarding respectively. Once extensible packet matching and pipeline processing mechanism is used in network virtualization, multiple virtual networks for different services could be realized on a single physical network infrastructure. Physical resources such as Virtual network n Virtual network 1 Physical Network Name-based Network IP-based Network Figure 10. Virtual networks and services Service type n Service type 1 OpenFlow switches, servers, and other network components are sliced and mapped as the virtual resources. For example, a virtual OpenFlow switch can be viewed as a virtualized switch instance having a subset of links, bandwidth and memory of the physical switch. A virtual resource group could be provided for each virtual network, which is customized to an application-specified service. Each virtual network could support different network logical architecture which is suitable for different application requirements. For example, in Figure 10, the content delivery services, such as Name-Based services etc., are deployed in one virtual network which is supporting the information-centric networking function, while the traditional IP services are deployed in another virtual network with IP-based routing and forwarding paradigm. V. CONCLUSION An autonomic OpenFlow-Based SDN Model is proposed in this paper. Based on the autonomic technologies and GANA architecture reference model from EFIPSANS project, a kind of autonomic OpenFlow-Based SDN model and key functions design are addressed in detail. The results of this paper could be proposed to some international standard organizations, such as ITU-T, IETF, and ETSI. We also hope that further investigations and deep analysis could be continued, and a demo development is also necessary to prove our conceptual design. REFERENCES [1] Software-Defined Networking: The New Norm for Network. ONF White Paper, April 13,2012 at https://www.opennetworking.org/images/stories/downloads/whitepapers/wp-sdn-newnorm.pdf [2] EU IST Future and Emerging Technologies, Situated and Autonomic Communication (SAC), at http://cordis.europa.eu/ist/fet/comms.htm [3] SDN and OpenFlow: A Tutorial; IPinfusion, at http://www.imsaa.org/tutorial_4.pdf [4] IBM article: Understand the autonomic manager concept: http://www- 128.ibm.com/developerworks/library/ac-amconcept/ [5] EFIPSANS Deliverable 1.7: Final draft of Autonomic Behaviours Specifications (ABs) for Selected Diverse Networking Environments, at http://www.efipsans.org/dmdocuments/infso-ict- 215549_EFIPSANS_CO_WP1_D1_7_Part1.pdf [6] EFIPSANS, Exposing the Features in IPv6 protocols that can be exploited/extended for the purposes of designing and build autonomic Networks and Services project, at http://efipsans.org/ [7] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, OpenFlow: Enabling innovation in campus networks, ACM Computer Communication Review, Apr. 2008. [8] B. Pfaff, et al., OpenFlow Specification, Version 1.3.0, April 16, 2012, https://www.opennetworking.org/images/stories/downloads/specificatio n/openflow-spec-v1.2.pdf [9] R. Sherwood, G. Gibb, K. Yap, G. Appenzeller, M. Casado, N. McKeown, and G. Parulkar, FlowVisor: A Network Virtualization Layer, OpenFlow Switch Consortium, Tech. Rep., October 2009. [10] The Named-Data Networking (NDN) project, under NSF Future Internet Architecture (FIA) program, http://named-data.org/ 823