AutoSlice: Automated and Scalable Slicing forSoftware-Defined Networks

Zdravko Bozakov and Panagiotis PapadimitriouInstitute of Communications Technology, Leibniz University of Hannover, Germany

{zdravko.bozakov, panagiotis.papadimitriou}@ikt.uni-hannover.de

ABSTRACTWe present AutoSlice, a virtualization layer that automatesthe deployment and operation of software-defined network(SDN) slices on top of shared network infrastructures. Auto-Slice enables substrate providers to resell their SDN to mul-tiple tenants while minimizing operator intervention. Atthe same time, tenants are given the means to lease pro-grammable network slices enabling the deployment of ar-bitrary services based on SDN principles. We outline thecontrol plane architecture of AutoSlice and discuss the mostchallenging aspects of the forwarding plane design with em-phasis on scalability.

Categories and Subject DescriptorsC.2.1 [Computer-Communication Networks]: NetworkArchitecture and Design

KeywordsSoftware-Defined Network, Network Virtualization, Caching

1. INTRODUCTIONNetwork virtualization comprises a viable solution for the

concurrent deployment and operation of isolated networkslices on top of shared network infrastructures [1]. Theemerging SDN paradigm facilitates the deployment of net-work services, by combining programmable switching hard-ware, such as OpenFlow, centralized control and network-wide visibility. These salient properties of SDNs can enablenetwork tenants to take control of their slices, implementingcustom forwarding decisions, security policies and configur-ing access control as needed.

A fundamental building block for SDN virtualization isFlowVisor [2], which enables slicing of the flow table inOpenFlow switches by partitioning it into so-called flows-paces. As a result, switches can be manipulated concur-rently by multiple controllers. Nevertheless, the instantia-tion of an entire vSDN topology is non-trivial, as it involves

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.CoNEXT Student’12, December 10, 2012, Nice, France.Copyright 2012 ACM 978-1-4503-1779-5/12/12 ...$15.00.

ASD

ASD

ASD

managementmodule

controllerproxy

controllerproxy

controllerproxy

SDN hypervisor

physical SDN

virtual SDN

virtual SDN Brequest

virtual SDNrequest

controller

SDNdomain

tenant

Figure 1: AutoSlice architecture overview.

numerous operations, such as mapping virtual SDN (vSDN)topologies, installing auxiliary flow entries for tunneling andenforcing flow table isolation. Since these operations re-quire considerable planning and management resources, weaim to develop a transparent virtualization layer, or SDNhypervisor, which automates the deployment and operationof arbitrary vSDN topologies with minimal intervention bythe substrate operator. In contrast to previous SDN virtu-alization efforts [3, 4], we focus on the scalability aspectsof the hypervisor design. Furthermore, AutoSlice optimizesresource utilization and mitigates flow-table limitations bymonitoring flow-level traffic statistics. In the remainder ofthis paper, we discuss the control and forwarding plane ar-chitecture of AutoSlice.

2. CONTROL PLANE OVERVIEWWe consider a network infrastructure provider offering

vSDN topologies to multiple tenants. A tenant’s vSDN re-quest comprises a set of nodes and links with certain re-quirements, such as switching capacity, link bandwidth, andlocation. Once a vSDN has been deployed, the tenant’scontroller can install flow entries as if accessing a dedicatedphysical SDN. We make no assumptions about the type of

3

service, i.e., the packet forwarding and processing rules thatthe tenant would like to deploy. We only assume that thephysical substrate consists of OpenFlow switches, each con-taining a flow table which can be sliced into logical segments.

We propose a distributed hypervisor architecture, depictedin Fig. 1, which can handle large numbers of flow table con-trol messages from multiple tenants. The hypervisor com-prises a management module (MM), and multiple controllerproxies (CPX) which are used to evenly distribute the con-trol load. We segment the physical substrate into multipleSDN domains and assign a dedicated CPX to each domain.Each CPX transparently manages the access to the corre-sponding domain switches. Currently, we assume that allSDN domains are operated by a single SDN provider; how-ever, multi-provider SDN slicing is possible by leveraging onnetwork virtualization architectures, such as [1].

Upon receiving a request, the MM maps the virtual SDNtopology to the resources available in each SDN domain,and assigns a subset of logical resources to each CPX. Sub-sequently, every CPX instantiates the allocated topologysegment by installing infrastructure flow entries in its do-main, which unambiguously bind traffic to a specific logicalcontext using tagging. Since isolation between tenants isessential, each CPX performs policy control on the flow ta-ble accesses and ensures that the resulting flow entries aremapped onto non-overlapping flowspaces. All control com-munication between a tenant’s controller and the forwardingplane is redirected through the CPX responsible for the cor-responding switch. Before installing a tenant flow entry toa switch, the proxy rewrites the control message, such thatall references to virtual resources are replaced by the cor-responding physical entities, and appropriate traffic taggingactions are appended. The state of each virtual node in agiven SDN domain is maintained solely by the correspondingproxy. Consequently, each CPX can independently migratevirtual resources (e.g., nodes, links) within its domain inorder to optimize intra-domain resource utilization. Globaloptimizations are coordinated by the MM.

The transparent control message translation enables ten-ants to install arbitrary packet processing rules within anassigned SDN slice, without adversely affecting concurrentusers. At the same time, the automation of the infrastruc-ture setup minimizes SDN operator intervention.

3. FORWARDING PLANEWe now consider the main challenges of the forwarding

plane design. In a multi-tenant environment a large numberof logical flow tables must be mapped onto the memory ofa single substrate switch. The CPX ensures the isolationof all virtual flow tables and also guarantees that all packetprocessing actions are applied in the correct sequence in casea connected group of virtual nodes is mapped to the sameswitch (e.g., using a loopback interface). The scalabilityof the platform would be severely restricted by the limitedflow table size in OpenFlow switches, which is typically inthe order of several thousands of entries. To overcome thislimitation, we deploy so-called auxiliary software datapaths(ASD) in the substrate network, similarly to [5]. Each SDNdomain is assigned an ASD consisting of a software switch,(e.g., OpenVSwitch), running on a commodity server. Incontrast to an OpenFlow switch, the available main memoryin a server is sufficient for storing a full copy of all logical flowtables required by the corresponding ASD. However, despite

the recent advances in software-based datapath architecturesand commodity servers, the divide between commodity andspecialized hardware still remains, with the latter offeringat least an order of magnitude larger switching capacity.

To circumvent these limitations, we exploit the Zipf prop-erty of aggregate traffic, i.e., the fact that a small fraction offlows account for most of the traffic volume. We use ASDsfor handling low-volume traffic flows (mice), while cachinga small number of high-volume (elephants) flows in the ded-icated switches. To this end, a set of low-priority, infras-tructure entries route traffic from the domain edge to theASD, when no high-priority flow entry has been cached at adomain switch (i.e., acting as a fallback path). The CPX se-lects the flow entries that will be cached, so that most of thetraffic is offloaded from the ASD. In addition, CPX ensuresthat cached flow entries do not alter the semantic integrityof the flow table rules by re-encoding flow entries as needed.An effective traffic offloading approach for IP forwardinghas been evaluated in [6]. The varying traffic demands anddiverse forwarding rules deployed by tenants in their vS-DNs introduce additional complexity on flow caching deci-sions. To this end, we are developing a caching mechanismwhich exploits the flow-level statistics exposed by OpenFlowswitches. In particular, we make offloading decisions basedon inferred traffic characteristics, such as traffic burstiness.

4. IMPLEMENTATION ANDFUTURE WORK

We have implemented a small-scale prototype, as proof-of-concept of the AutoSlice architecture, using Pronto 3295switches and commodity servers with OpenVSwitch as ASDs.We employ OpenFlow 1.0 and VLAN for packet tagging.Our prototype implementation currently comprises modulesfor switch flow table access control (built on top of FlowVi-sor), control traffic classification, flow caching, and vSDNmapping. Our flow caching approach relies on random sam-pling which ensures undistorted estimates of traffic char-acteristics while mitigating the control load associated withflow statistics requests. In addition, we aim to study the dy-namic segmentation of the substrate into SDN domains asvSDNs are provisioned or released, the suitability of existingvirtual network embedding algorithms for vSDN mapping,the collaboration among CPX for operations across multipleSDN domains (e.g., vSDN migration) and the efficiency offlow caching techniques.

5. REFERENCES[1] G. Schaffrath, et al., Network Virtualization

Architecture: Proposal and Initial Prototype, Proc.ACM SIGCOMM VISA 2009.

[2] R. Sherwood, et al., Can the Production Network Bethe Testbed?, Proc. USENIX OSDI 2010.

[3] M. Casado, T. Koponen, R. Ramanathan, and S.Shenker, Virtualizing the network forwarding plane.Proc. ACM CONEXT PRESTO 2010.

[4] E. Salvadori, et al., Generalizing virtual networktopologies in OpenFlow-based networks, Proc. IEEEGLOBECOM 2011.

[5] M. Yu, et al., Scalable flow-based networking withDIFANE, Proc. ACM SIGCOMM 2010.

[6] N. Sarrar, et al., Leveraging’s Zipf’s Law for TrafficOffloading, ACM SIGCOMM CCR, 2012.

4