en-US/gsoc-tuna.xml

<?xml version='1.0' encoding='utf-8' ?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "CloudStack_GSoC_Guide.ent">
%BOOK_ENTITIES;
]>

<!-- Licensed to the Apache Software Foundation (ASF) under one
 or more contributor license agreements.  See the NOTICE file
 distributed with this work for additional information
 regarding copyright ownership.  The ASF licenses this file
 to you under the Apache License, Version 2.0 (the
 "License"); you may not use this file except in compliance
 with the License.  You may obtain a copy of the License at
 
   http://www.apache.org/licenses/LICENSE-2.0
 
 Unless required by applicable law or agreed to in writing,
 software distributed under the License is distributed on an
 "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 KIND, either express or implied.  See the License for the
 specific language governing permissions and limitations
 under the License.
-->

<chapter id="gsoc-tuna">
        <title>Nguyen's 2013 GSoC Proposal</title>
        <para>This chapter describes Nguyen 2013 Google Summer of Code project within the &PRODUCT; ASF project. It is a copy paste of the submitted proposal.</para>
	<section id="add-xen-xcp-support-for-gre-sdn-controller">
		<title>Add Xen/XCP support for GRE SDN controller</title>
		<para>
			"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."
		</para>
	</section>
	<section id="Abstract">
		<title>Abstract</title>
		<para>
			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.
		</para>
		<para>
			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.
		</para>
		<para>
			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.
		</para>
	</section>
	<section id="design-desription">
		<title>Design description</title>
		<para>
			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:
		</para>
		<para>
			<emphasis role="bold">OVS tunnel manager:</emphasis> Consist of OvsElement and OvsTunnelManager.
		</para>
		<para>
			OvsElement is used for controlling Ovs tunnel lifecycle (prepare, release)
		</para>
		<itemizedlist>
			<listitem>
				<para>prepare(network, nic, vm, dest): create tunnel for vm on network to dest</para>
			</listitem>
			<listitem>
				<para>release(network, nic, vm): destroy tunnel for vm on network</para>
			</listitem>
		</itemizedlist>
		<para>
			OvsTunnelManager  drives  bridge  configuration  and  tunnel  creation  via  calling  respective commands to Agent.	
		</para>
		<itemizedlist>
			<listitem>
				<para>destroyTunnel(vm, network): call OvsDestroyTunnelCommand to destroy  tunnel for vm on network</para>
			</listitem>
			<listitem>
				<para>createTunnel(vm, network, dest): call OvsCreateTunnelCommand to create  tunnel for vm on network to dest</para>
			</listitem>
		</itemizedlist>
		<para>
			<emphasis role="bold">OVS tunnel plugin:</emphasis> These are ovstunnel and ovs-vif-flows.py script, writen as XAPI plugin. The OVS tunnel manager will call them via XML-RPC.
		</para>
		<para>
			Ovstunnel plugin calls corresponding vsctl commands for setting up the OVS bridge, creating GRE tunnels or destroying them.
		</para>
		<itemizedlist>
			<listitem>
				<para>setup_ovs_bridge()</para>
			</listitem>
			<listitem>
				<para>destroy_ovs_bridge()</para>
			</listitem>
			<listitem>
				<para>create_tunnel()</para>
			</listitem>
			<listitem>
				<para>destroy_tunnel()</para>
			</listitem>
		</itemizedlist>
		<para>
			Ovs-vif-flow.py clears or applies rule for VIFs every time it is plugged or unplugged from a OVS bridge.	
		</para>
		<itemizedlist>
			<listitem>
				<para>clear_flow()</para>
			</listitem>
			<listitem>
				<para>apply_flow()</para>
			</listitem>
		</itemizedlist>
		<para>
			<emphasis role="bold">OVS command/answer:</emphasis> It is designed under the format of requests and answers between Manager and Plugin. These commands will correspondence exactly the mentioned manipulations.
		</para>
		<itemizedlist>
			<listitem>
				<para>OvsSetupBridgeCommand</para>
			</listitem>
			<listitem>
				<para>OvsSetupBridgeAnswer</para>
			</listitem>
			<listitem>
				<para>OvsDestroyBridgeCommand</para>
			</listitem>
			<listitem>
				<para>OvsDestroyBridgeAnswer</para>
			</listitem>
			<listitem>
				<para>OvsCreateTunnelCommand</para>
			</listitem>
			<listitem>
				<para>OvsCreateTunnelAnswer</para>
			</listitem>
			<listitem>
				<para>OvsDestroyTunnelCommand</para>
			</listitem>
			<listitem>
				<para>OvsDestroyTunnelAnswer</para>
			</listitem>
			<listitem>
				<para>OvsFetchInterfaceCommand</para>
			</listitem>
			<listitem>
				<para>OvsFetchInterfaceAnswer</para>
			</listitem>
		</itemizedlist>
		<para>
			<emphasis role="bold">OVS Dao/VO</emphasis> 
		</para>
		<itemizedlist>
			<listitem>
				<para>OvsTunnelInterfaceDao</para>
			</listitem>
			<listitem>
				<para>OvsTunnelInterfaceVO</para>
			</listitem>
			<listitem>
				<para>OvsTunnelNetworkDao</para>
			</listitem>
			<listitem>
				<para>OvsTunnelNetworkVO</para>
			</listitem>
		</itemizedlist>
	</section>
	<section id="integrate-floodLight-as-sdn-controller">
		<title>Integrate FloodLight as SDN controller</title>
		<para>
			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.
		</para>
	</section>
	<section id="Deliverables">
		<title>Deliverables</title>
		<para>
			GRE has been used as isolation method in CloudStack when deploy with Xen/XCP hosts.
		</para>
		<itemizedlist>
			<listitem>
				<para>User set sdn.ovs.controller parameter in Global Setting to true. He deploys Advance Networking and chooses GRE as isolation method</para>
			</listitem>
			<listitem>
				<para>Make use of Floodlight instead of native SDN controller.</para>
			</listitem>
		</itemizedlist>
	</section>
	<section id="About-me">
		<title>About me</title>
		<para>
			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:
		</para>
		<itemizedlist>
			<listitem>
				<para>Encrypt Data Volume for VMs.</para>
			</listitem>
			<listitem>
				<para>Dynamic Allocate Memory for VMs by changing policy on Squeeze Daemon.</para>
			</listitem>
			<listitem>
				<para>AutoScale without using NetScale.</para>
			</listitem>
			<listitem>
				<para>Deploy a new SystemVM type for Intrustion Detection System.</para>
			</listitem>
		</itemizedlist>
		<para>
			Given the working experience and recent researches, I have obtained remarkably the understanding of specific knowledges to carry on this project, details as follow: 
		</para>
		<itemizedlist>
			<listitem>
				<para>Java source code on CloudStack: Design Pattern, Spring framework.</para>
			</listitem>
			<listitem>
				<para>Bash, Python programming.</para>
			</listitem>
			<listitem>
				<para>XAPI plugin.</para>
			</listitem>
			<listitem>
				<para>XML-RPC.</para>
			</listitem>
			<listitem>
				<para>OpenVSwitch on Xen.</para>
			</listitem>
		</itemizedlist>
		<para>
			Other knowledges: 
		</para>
		<itemizedlist>
			<listitem>
				<para>XAPI RRD, XenStore.</para>
			</listitem>
			<listitem>
				<para>Ocaml Programming (XAPI functions).</para>
			</listitem>
		</itemizedlist>
	</section>
</chapter>