Nguyen's 2013 GSoC Proposal

Nguyen's 2013 GSoC Proposal This chapter describes Nguyen 2013 Google Summer of Code project within the &PRODUCT; ASF project. It is a copy paste of the submitted proposal. +

+ Add Xen/XCP support for GRE SDN controller + + "This project aims to enhance the current native SDN controller in supporting Xen/XCP and integrate successfully the open source SDN controller (FloodLight) driving Open vSwitch through its interfaces." + +

+ Abstract + + SDN, standing for Software-Defined Networking, is an approach to building data network equipments and softwares. It were invented by ONRC, Stanford University. SDN basically decouples the control from physical networking boxes and given to a software application called a controller. SDN has three parts: controller, protocols and switch; In which, OpenFlow is an open standard to deploy innovative protocols. Nowaday, more and more datacenters use SDN instead of traditional physical networking boxes. For example, Google announced that they completely built its own switches and SDN confrollers for use in its internal backbone network. + + + OpenvSwitch, an open source software switch, is widely used as a virtual switch in virtualized server environments. It can currently run on any Linux-based virtualization platform, such as: KVM, Xen (XenServer, XCP, Xen hypervisor), VirtualBox... It also has been ported to a number of different operating systems and hardware platforms: Linux, FreeBSD, Windows and even non-POSIX embedded systems. In cloud computing IaaS, using OpenvSwitch instead of Linux bridge on compute nodes becomes an inevitable trend because of its powerful features and the ability of OpenFlow integration as well. + + + In CloudStack, we already have a native SDN controller. With KVM hypervisor, developers can easily install OpenvSwitch module; whereas, Xen even has a build-in one. The combination of SDN controller and OpenvSwitch gives us many advanced things. For example, creating GRE tunnels as an isolation method instead of VLAN is a good try. In this project, we are planning to support GRE tunnels in Xen/XCP hypervisor with the native SDN controller. When it's done, substituting open-sources SDN controllers (floodlight, beacon, pox, nox) for the current one is an amazing next step. + +

+ Design description + + CloudStack currently has a native SDN Controller that is used to build meshes of GRE tunnels between Xen hosts. There consists of 4 parts: OVS tunnel manager, OVS Dao/VO, Command/Answer and Ovs tunnel plugin. The details are as follow: + + + OVS tunnel manager: Consist of OvsElement and OvsTunnelManager. + + + OvsElement is used for controlling Ovs tunnel lifecycle (prepare, release) + + + + prepare(network, nic, vm, dest): create tunnel for vm on network to dest + + + release(network, nic, vm): destroy tunnel for vm on network + + + + OvsTunnelManager drives bridge configuration and tunnel creation via calling respective commands to Agent. + + + + destroyTunnel(vm, network): call OvsDestroyTunnelCommand to destroy tunnel for vm on network + + + createTunnel(vm, network, dest): call OvsCreateTunnelCommand to create tunnel for vm on network to dest + + + + OVS tunnel plugin: These are ovstunnel and ovs-vif-flows.py script, writen as XAPI plugin. The OVS tunnel manager will call them via XML-RPC. + + + Ovstunnel plugin calls corresponding vsctl commands for setting up the OVS bridge, creating GRE tunnels or destroying them. + + + + setup_ovs_bridge() + + + destroy_ovs_bridge() + + + create_tunnel() + + + destroy_tunnel() + + + + Ovs-vif-flow.py clears or applies rule for VIFs every time it is plugged or unplugged from a OVS bridge. + + + + clear_flow() + + + apply_flow() + + + + OVS command/answer: It is designed under the format of requests and answers between Manager and Plugin. These commands will correspondence exactly the mentioned manipulations. + + + + OvsSetupBridgeCommand + + + OvsSetupBridgeAnswer + + + OvsDestroyBridgeCommand + + + OvsDestroyBridgeAnswer + + + OvsCreateTunnelCommand + + + OvsCreateTunnelAnswer + + + OvsDestroyTunnelCommand + + + OvsDestroyTunnelAnswer + + + OvsFetchInterfaceCommand + + + OvsFetchInterfaceAnswer + + + + OVS Dao/VO + + + + OvsTunnelInterfaceDao + + + OvsTunnelInterfaceVO + + + OvsTunnelNetworkDao + + + OvsTunnelNetworkVO + + +

+ Integrate FloodLight as SDN controller + + I think that we maybe deploy FloodLight Server as a new SystemVM. This VM acts like current SystemVMs. One Floodlight SystemVM per Zone, so it can manage for virtual switches under this zone. + +

+ Deliverables + + GRE has been used as isolation method in CloudStack when deploy with Xen/XCP hosts. + + + + User set sdn.ovs.controller parameter in Global Setting to true. He deploys Advance Networking and chooses GRE as isolation method + + + Make use of Floodlight instead of native SDN controller. + + +

+ About me + + My name is Nguyen Anh Tu, a young and enthusiastic researcher in Cloud Computing Center - Viettel Research and Development Institute, Vietnam. Since last year, we has built Cloud Platform based on CloudStack, starting with version 3.0.2. As the results, some advanced modules were successfully developed, consists of: + + + + Encrypt Data Volume for VMs. + + + Dynamic Allocate Memory for VMs by changing policy on Squeeze Daemon. + + + AutoScale without using NetScale. + + + Deploy a new SystemVM type for Intrustion Detection System. + + + + Given the working experience and recent researches, I have obtained remarkably the understanding of specific knowledges to carry on this project, details as follow: + + + + Java source code on CloudStack: Design Pattern, Spring framework. + + + Bash, Python programming. + + + XAPI plugin. + + + XML-RPC. + + + OpenVSwitch on Xen. + + + + Other knowledges: + + + + XAPI RRD, XenStore. + + + Ocaml Programming (XAPI functions). + + +