SOX - A Generalized Smart Openflow Controller

SOX - A Generalized and ExtensibleS mart Network O penflow Controller (X)Min Luo, Yingjun Tian, Quancai Li, Jiao Wang, Wu ChouShannon Lab, Huawei Technologies Co., Ltd.October 21, 20121 IntroductionNetwork infrastructure is fast evolving, since the dawn of the Internet. It has made the currently prevailing TCP-IP or OSI-7 layers based architecture and realization increasingly complex and difficult to manage. Numerous protocols are applied on many layers of network stacks, and network components from different vendors are heterogeneous affected by differences in standard protocol implementations and the special features added to support certain applications. Even though a large percentage of IT budget have been invested in data networking, the current infrastructure is still struggling to cope with the needs from new applications that are still arising rapidly.Software Defined Networking (SDN) has the potential to significantly simplify the network architecture and protocol stacks with increased flexibility, programmability, manageability, and stronger control of QoS. Openflow (OF) protocols [1] from ONF provide the protocol interface between switches and controllers, upon which central controllers can control the data forwarding network. However, since its first publication in 2009, OF protocols have been evolving rapidly with the advances in SDN technologies. To enhance the flexibility, reliability, and advanced networking capabilities, the subsequent standard releases after OF 1.0, i.e. OF1.1 and 1.2, introduced many core functionalities such as multi-flow tables and multi-controllers, in addition to other critical needed features such as IPv6, and MPLS. These desired new capabilities came with a cost, in terms of their renewed complexity and difficulty for efficient system architecture and implementation, regardless it is an OF 1.2/1.1 controller or an OF 1.1/1.2 switch. Moreover, changes in OF 1.2 are so significant that ONF declared OF 1.2/1.1 as incompatible with OF 1.0. It should be feasible to design a network controller for each version of the OF standard. But many incompatible controllers needed on the control plan will lead to a network management nightmare, leaving aside that incompatible protocols, switches, and controllers can also cause network fragmentation. Obviously, it would be advantageous to design and implement a generalized network controller that can discover and manage a network with mixed switches supporting different Openflow standard versions.In this white paper, we describe a generalized controller SOX, Smart Network Openflow Controller, to deal with above mentioned circumstances. It is architected, designed, andimplemented with the aim to control a SDN network with a mixed type of switches from different or incompatible standard versions. Specifically we describe the design principle, features, and the functional requirements, based on and derived from OF 1.2 and 1.0 specifications, core functional and non-functional requirements, architectural considerations, and core controller components. We will cover the status of SOX, especially what have been done and what have been demonstrated in the recent ONF PlugFest event.As SDN is “SOFTWARE” defined, we adopted sound software engineering practice in the architecture and design of SOX from its early days. As a consequence, it also allows us to discuss the whole life-cycle of SOX.2 SOX Architecture and Design Objectives andConsiderationsAs its name implies, SDN should take advantage the effective practice that has been learned from several decades in software engineering (SE). In SOX, we made a strong effort to follow a more disciplined SE approach from its early stage of SOX inception.Our goal is to architect, design, and implement an open, generalized, flexible, easy to extend, highly scalable and reliable SDN-Openflow controller(s) by applying some proven or best available SE principles, techniques from recent advances in distributed computing, design patterns, and frameworks.We effectively applied model-driven architecture and development (MDA-D) framework for the whole life-cycle of SOX, from requirements gathering and modeling, to analysis and design models, and to specific technology dependent implementation. SOX component and object models, and their standard interfaces were established with UML 2.0 with required SOX extensions. Following MDA-D, those models could be (mostly even at this time) transformed and traced, and some automatic code generations could also be supported.In order to model and implement future networking architecture and dealing with evolving protocols, model artifacts were parameterized, so that they could be adaptively configured and instantiated to meet the current (Openflow) standard versions or the potential future extension needs.Another important SE principle is reuse. Some SOX model(s) were created after taking an extensive survey and study of various open source OF 1.0 controllers, most noticeably NOX [3], Maestro [4], and Floodlight [5]. In order to support OF 1.2, SOX models were built, and then refactored and extended by applying well-known and widely adopted sound SE techniques, design patterns, and frameworks to improve their generality, extensibility, and maintainability.In addition, SOX tried to address the problem of automatic configuration and extension based onapplication scenarios and environments. However, the effectiveness of such support is still anon-going study.3 Key Features and Requirements of SOX3.1 Key Features for SOX OF 1.2 ControllersSOX supports the following key features such as OF protocol support, network protocol and control, switch, and link management ,etc., which are depicted in Figure 1.Figure 13.2 Generalized Controller that Supports both OF1.2 and its IncompatibleAncestor OF 1.0One of the key features of SOX is to be a generalized network controller with a control infrastructure that can backward support OF 1.0. As discussed earlier, due to the significant changes in features, OF 1.2 was declared to be incompatible with OF 1.0, and no OF 1.2 switches were announced or made publically available until Ericsson‟s software implementation[6] finally became workable in August 2012. Most of switch vendors still only support OF 1.0, or in most cases, hybrid switches that could be configured to run in traditional “IP” mode or OF 1.0 mode. SOX‟s capability to support both OF 1.2 and 1.0 enabled networks. It is therefore, supports the testing of common features between the two versions, but more importantly, it effectively reduces the risk of network fragmentation due to non-inter-operable OF 1.0 or 1.2 standards where switches and controllers could only run and control their own network pieces.3.3 Use Case Modeling for Functional Requirements“Use case driven” is another ingredient for modern SE. SOX use cases were modeled around two key constituents of SDN-OF, namely the (logically) centralized controller and all the switches in the managed network, as depicted in Figure 2. In addition, there are special use cases for network configuration and management, host management, and management applications.Figure 23.4 Key Non-functional Requirements of SOXSOX used the design guidelines which are similar to those outlined in ONIX [2]:●Generality：In addition to what ONIX described, we consciously designed SOX to be a“generalized” controller that not only support s OF 1.2, but it also backward-support OF1.0. In fact, more “generally”, it is extensible to support any protocol that adopts SDNcore concepts of separating global network control logic and the data forwarding in each individual switch.●Scalability: With its distinguished architecture and design, SOX could dynamicallyadjust the number of controllers in “active/operational” mode based on the traffic needsand global network states.●Reliability: SOX multi-controllers could also enable high reliability, and eliminate thepotential “single point of failure” that haunts the SDN-OF deployment. In addition, SOXcan properly and effectively process exceptions from the controller(s) and other networkelements.●Performance●Extensibility: SOX properly and effectively applied MDA-D, and refactoring techniqueswithout significant re-inventing in its development. This practice enabled the fastadaptation of SOX when supporting the evolving OF standards. More importantly, itsupports the advances of next generation data network architecture, protocols, andmanagement applications under SDN.●Security●Simplicity: Using its internet based GUI, SOX enables easier network construction,(re)configuration and management.4 SOX Architecture and Core ComponentsFigure 3 depicts the overall SOX architecture and core components, mostly following the guidelines and some notations from ONIX [2] and other open source reference implementations.Figure 34.1 Innovative Multi-ControllersThe multi-controller architecture in SOX was based on some distinguished architecture and designs. Some recent advances in distributed and computing, proven design patterns, and frameworks were adapted then applied to SOX‟s multi-controller architecture. SOX can take advantage of recent advances in multi-core servers, and it could be deployed and run at the thread or process level, while significantly reducing the necessary communication among controllers.SOX could dynamically adjust the number of controllers to manage data traffic load in the data forwarding network, based on some real time “observation” of network states. Other techniques were also developed to further improve the performance and reliability of SOX.4.2 Application and traffic-driven Adaptive Multi-flow Tables:To overcome issues with expensive and limited memory space for large routing tables and the cost of search/matching in the traditional switches/routers, multi-flow tables were introduced as one of the key advances from OF 1.0 to 1.1/1.2. But no such OF switches or controllers were made publically available till recently, as it adds significant technical difficulties in its design and implementation, regardless it is the switching hardware or software components of the controller. SOX‟s solution to implement multi-flow tables was based on months of extensive research, and many rounds of design and (re)assessments. Two sets of logic for multi-flow tables were provided eventually:a)Through proper OF 1.2 based feature discovery, it can learn the “capabilities” of compliantswitches, generate and distribute the right form of flow tables or flow entry modificationinstructions to every switch that is in need.b) A special logic was d esigned to further optimize SOX‟s multi-flow logic based onapplication scenarios, traffic types, service requirements and other factors.4.3 IPv6 SupportCurrently, SOX supports proper parsing of IPv6 packets and related internetworking needs among IPv6 enabled hosts.4.4 VLAN Support and Limited BroadcastingUsing its internet-based GUI application, SOX enables easy configuration of VLAN. Moreover, based on such capabilities, SOX could provide broadcasting capability to a selected set of switches.4.5 MPLS SupportSOX can properly process MPLS tags and make and disseminate routing decisions in its flow entries.5 Test Cases and Lessons Learned from ONFPlugFest 2012ONF and InCNTRE at Indiana University co-hosted the Fall 2012 PlugFest event from October 8 to October 12. Evaluation tests were conducted under the administration of ONF/InCNTRE, flow entry verificatio n on SOX‟s GUI, and manual switch side verifications by participating vendors were conducted to verify the SOX‟s functionalities. SOX successfully tested the following features:i.Demonstrated core OF 1.2 features with a network of pure Huawei OF 1.2hardware [7] and software switchesii.Automatically topology discovery of both OF1.0 and OF 1.2 switches, including their detailed featuresiii.Demonstrated inter-networking with mixed OF 1.2 and 1.0 switches, including Huawei …s OF 1.2 hardware prototype [7] and software switches, IBM, and NECOF 1.0 switches, and hybrid or pure OF 1.0 switches from multiple vendors suchas IBM, NEC(2 type of switches), HP, Extreme, and Centech.5.1 OF 1.2 Core FeaturesWith a network of pure OF 1.2 hardware and software switches, the following tests were conducted and tested successfully.5.1.1 Innovative multi-controller design and implementation:As depicted in Figure 4, when network packet injection rate was increased from R1 to R5, SOX reacted correctly and increased the number of controllers from 2 to 6. Then, when the injection rate was dropped, it properly responded by decreasing the number of controllers. In addition, SOX is able to provide automatic fail-over in face of controller failures.Figure 45.1.2 Application and traffic-aware, adaptive multi-flow table logicWe demonstrated that SOX can support multi-flow table logic in the two modes discussed before: one for generic conforming OF 1.2 switches (the software switch [6]), and one for specialized application and traffic-aware, QoS dependent routing decisions (Huawei‟shardware switch [7]).5.1.3 Support for VLAN, IPv6 and MPLSVLAN configuration and IPv6 support were demonstrated in the PlugFest as part of OF 1.2 testing.5.2 Support for Mixed Network with both OF 1.2 and 1.0 SwitchesThe control of mixed network test for SOX started with a network consist of Huawei OF 1.2 switches. Soon after an IBM OF 1.0 hybrid switch was configured properly in both the control anddata plane, SOX GUI immediately displayed a network with the two connected switches with their key features (such as OF version #, dpid #, IP address, etc.). Inter-networking was proved valid through pinging each other from hosts connected to each switch. Versifications were made through investigation the examination of flow entries stored on the controller, and also manual flow-entry look-ups on vendor‟s switch console. Later another NEC OF 1.0 switch was attached to the network and tested with the same procedure, and eventually forming an operational Triangular network with both OF1.2 and OF 1.0 switches controlled by the generalized controller SOX, depicted in Figure 5.Figure 55.3 Inter-operability Testing for Pre-configured OF 1.0 Testbed 2The control and inter-operability of SOX on mixed switch network were tested on an unfamiliar network by adding more switches from different vendors, as originally configured as Testbed 2 in the PlugFest. As each switch was configured, the SOX controller correctly discovered the true network topology, while the topology expanded from the 4 initially disconnected switches to its final form of a designed topology as depicted in Figure 6. The inter-networking of switches was verified from flow entries generated by the SOX controller and by examining the flow entries at the switch side.Figure 66 SummaryIn this white paper, we described and summarized design principles, key features, functional and non-functional requirements in building a generalized and extensible smart network controller, SOX. It was designed according to some proven best software engineering practices, advances in distributed computing, and design patterns and frameworks for the desired generality, scalability and reliability, interoperability and extensibility. Architecture considerations and core components were briefly covered. Some key test cases conducted in the recent ONF 2012 PlugFest were also included.SOX will be further improved on performance, reliability, network virtualization support, extension and integration with cloud computing and related standards, and security. In addition, algorithms for management applications will be investigated with the focus on better routing, resource utilization, and automatic network management, taking advantage of the global topology, network states, and traffic flow pattern information.Acknowledgement: Authors would like to thank their colleagues of the SOX R&D team in China, especially Xiuli Zheng, Gang Cao, Sihuan Xu, Xiaorong Wu, Qing Li, Yongcan Wang, Ke Ling , and many others. We would also like to extend our appreciation again to staffmembers at the SDN Lab, InCNTRE and vendors who collaborated with us in the PlugFest event.References1. The Openflow Specifications 1.0, 1.1, 1.2 … ,https:///about/onf-documents2. “Onix: A distributed control platform for large-scale production networks”, TeemuKoponen, Martin Casado, Natasha Gude, Jeremy Stribling, Leon Poutievski, MinZhu, Rajiv Ramanathan, Yuichiro Iwata, Hiroaki Inoue, Takayuki Hama, and ScottShenker, Operating Systems Design and Implementation (OSDI), October 20103. “NOX: Towards an Operating System for Networks”, N. Gude, T. Koponen, J. Pettit,B. Pfaff, M. Casado, N. McKeown, and S. Shenker, ACM SIGCOMM ComputerCommunication Review, July 2008.Also /nox/about-nox/4. "Maestro: Achieving Scalability and Coordination in Centralized Network ControlPlane", Ph.D. Thesis, Zheng Cai,, Rice University, 2011.Source at /p/maestro-platform/5. Floodlight: An Open SDN Controller, /6. OpenFlow 1.2 compatible user-space software switch implementation,Ericsson ,August 2012, https:///CPqD/of12softswitch7. Huawei Openflow 1.2 Compatible Hardware Switch Prototype, API Spec., Huawei,September 2012。