ABSTRACTIn enterprise networks, policies (e.g., QoS or security) areoften defined based on the categorization of hosts along di-mensions such as the organizational role of the host (facultyvs. student), and department (engineering vs. sales). Whilecurrent best practices (VLANs) help when hosts are cate-gorized along a single dimension, policy may often needto be expressed along multiple orthogonal dimensions. Inthis paper, we make three contributions. First, we argue forAttribute-Carrying IPs (ACIPs), where the IP address allo-cation process in enterprises considers attributes of a hostalong all policy dimensions. ACIPs enable flexible policyspecification in a manner that may not otherwise be feasibleowing to the limited size of switch rule-tables. Second, wepresent Alpaca, algorithms for realizing ACIPs under prac-tical constraints of limited-length IP addresses. Our algo-rithms can be applied to different switch architectures, andwe provide bounds on their performance. Third, we demon-strate the importance and viability of ACIPs on data col-lected from real campus networks.
1. INTRODUCTIONManaging large enterprise networks is challenging. A typ-
ical enterprise has many users who belong to different de-partments (e.g., sales and engineering, or computer scienceand history), and play different roles (e.g., faculty, staff, ad-ministrators, and students). In addition, the network supportsdiverse end-hosts running different operating systems andoffering different services. In response, network administra-tors want to enforce policies—such as access control andquality of service—that group hosts along multiple differentdimensions. For instance, one policy may restrict access to adatabase to all employees in the sales department, while an-
Permission to make digital or hard copies of all or part of this work for personalor classroom use is granted without fee provided that copies are not made ordistributed for profit or commercial advantage and that copies bear this noticeand the full citation on the first page. Copyrights for components of this workowned by others than ACM must be honored. Abstracting with credit is per-mitted. To copy otherwise, or republish, to post on servers or to redistribute tolists, requires prior specific permission and/or a fee. Request permissions [email protected].
other may offer a higher bandwidth limit to senior managersacross all departments, and yet another may restrict accessfor old hosts running a less secure operating system.
1.1 Enforcing Policies in Today’s Enter-prises
To enforce policies in today’s enterprises, network ad-ministrators typically rely on virtual local area networks(VLANs) [1]. A host joining the network is assigned to aVLAN based on its MAC address or the physical port ofthe access switch. Hosts in the same VLAN are assignedan IP address in the same IP prefix, even if they are notlocated near each other. Traffic flows freely between hostsin the same VLAN, while traffic between different VLANstraverses an IP router that can enforce policy. Since a hostcan only belong to a single VLAN, administrators typicallyassign hosts to VLANs based on a single dimension (e.g.,department or role), which has several major limitations:
• The routers interconnecting VLANs need long lists ofdata-plane “rules” to classify traffic along all relevant“dimensions” of the source and destination hosts.
• No security or QoS policies can be imposed on intra-VLAN traffic, forcing administrators to use a VLANonly to group hosts that should “trust” each other.
• Since VLAN tags are removed from traffic destined tothe Internet, the border router must classify all returntraffic from the Internet to assign VLAN tags.
For instance, suppose a security policy depends on both userrole and department. If VLANs were created based on theuser’s department, then expressing a policy based on role ina concise fashion is challenging. And, if two users in the dif-ferent department are close to each other, the traffic followsinefficient paths through intermediate routers to go betweenVLANs.
The rise of more flexible network switches, with open in-terfaces to separate control software, enables an attractivealternative. In recent years, switches built with commoditychipsets expose a pipeline of rule-tables that perform match-action processing on packet headers. While the rule tablesare relatively small (with small thousands of rules per stage,to limit power and cost), the switches support programmatic
interfaces (e.g., OpenFlow, OF-Config, and OVSDB [2]) thatenable new ways of controlling the network by installingthe rules in support of higher-level policies. One natural ap-proach, adopted in the early Ethane system [3], directs thefirst packet of each flow to a central controller, which con-sults a database—containing all the relevant host attributesand high-level policies—and reactively install rules for for-warding the remaining packets of the flow. However, reac-tive, fine-grained solutions like Ethane have high overheadand do not scale to large enterprises. FlowTags [4] tags pack-ets and uses the tags to enforce network policies. Yet, thisapproach, when applied to enterprise networks, requires in-stalling many extra tagging rules at the edge switches to clas-sify hosts along all dimensions. Instead, we need a proac-tive design that can aggregate hosts along many dimensions,while keeping switch rule tables small.
1.2 Attribute-Carrying IP AddressesIn the current enterprise networks, although IP addresses
are assigned based on attributes (e.g., a separate IP pre-fix per VLAN), it is just on a single dimension. We arguethat a complete IP address management scheme should con-sider all dimensions and enable compact representation ofpolicies. Our key idea is to assign each host an IP addressbased on all dimensions of the policy—that is, an attribute-carrying IP address (ACIP). Our solution, Alpaca (algo-rithms for policies on attribute-carrying addresses), com-putes an efficient address assignment, based on the policydimensions and the attributes of individual hosts, and a com-pact list of switch rules that realize a specific network policy.
Alpaca proactively generates a small number of coarse-grained rules in the switches, without using VLANs. Alpacagreatly simplifies enterprise management by (i) enabling ad-ministrators to specify policies on many orthogonal dimen-sions while achieving an order of magnitude reduction inrules; (ii) allowing policy to be correctly maintained evenwhen a host connects to the network at a new location;and (iii) simplifying federated management, where differentteams manage different parts of the enterprise network.
While Alpaca has many potential advantages, severalpractical issues must be considered:
Limited IP address space: Since most enterprises havelimited IP address space, a naive ACIP assignment can easilyexhaust all the available bits.
Heterogenous group sizes: Some combinations of policyattributes are much more common than others. As such, anefficient address assignment cannot simply devote a portionof the bits to representing group size.
Minimizing churn: It is important to support changes inthe policy attributes associated with a host (e.g., due to a usermoving to a different role or department), or changes in theset of attributes themselves (e.g., due to the creation of a newdepartment).
Multi-stage switch pipelines: Rather than assumingswitches have a single rule table (as in OpenFlow 1.0 [5]),a practical solution should capitalize on the multi-stagepipelines in modern switch chipsets [6–8].
We propose a family of algorithms to generate ACIPs and
the associated rule tables, starting with a simple strawmanthat devotes a separate set of address bits to each policy di-mension. This solution minimizes the number of rules butconsumes too much IP address space, making it infeasiblein most practical settings. We then propose two other al-gorithms that can keep the number of rules small, whilerespecting constraints on the number of bits in the IP ad-dress space. Our algorithms optimize based on the charac-teristics of modern switch chipsets. Conventionally, switchchip-sets have a single TCAM rule-table that supports a fewthousands of wildcard rules matching on multiple headerfields [5, 9, 10]. More recently, we are seeing the emergenceof switch chip-sets with a pipeline of multiple tables, whereeach table could be a TCAM or a larger SRAM that supportsprefix matching on source IP or destination IP [6–8]. Assuch, our first algorithm generates ACIPs that enable poli-cies to be expressed by solely IP prefixes, useful for rule ta-bles that support IP prefix matching. Our second algorithmtargets both single-table switches and multi-table switches,generating rules that perform arbitrary wildcard matching onIP addresses, in exchange for a reduction in the number ofrules. Together, these algorithms can capitalize on the uniquecapabilities of a variety of commodity switch architectures.
In the next section, we present a case study of multiplecampus networks, to underscore the need for policies alongmultiple dimensions. Section 3 introduces ACIPs and formu-lates the optimization problem Alpaca must solve, followedby Section 4 that presents our two algorithms. Using accesscontrol data from two large campuses, the experiments inSection 5 show that Alpaca can reduce the number of ACLrules on existing networks by 60%−68% for switches withmultiple tables and by 40%−96% for switches with a singletable, while requiring only 1 more bit of the IP address spacethan needed to represent the number of hosts in the network.Further, Alpaca can support futuristic scenarios with poli-cies based on multiple dimensions, while requiring an orderof magnitude fewer rules than VLAN-based configurationsoptimized for a single dimension. Section 6 presents relatedwork, and Section 7 concludes the paper.
2. CASE STUDY: DIVERSE ENTER-PRISE POLICIES
In this section, we present a case study of 25 enterprisenetworks, to identify the challenges in representing sophisti-cated policies, and the implications for Alpaca. Specifically:• We present a qualitative analysis of the security andquality-of-service policies employed by 22 universities, plusone individual department that runs its network separatelyfrom the campus IT group. The analysis indicates that net-works must often apply policy along several logical dimen-sions, with multiple attributes as possible categories in eachdimension. However, the analysis also points to policies thatare desirable but difficult to realize in practice.•We analyze router configuration data from two other largecampuses. The analysis provides further confirmation thatthere is significant commonality in policy across hosts, but
also points to how an inefficient assignment of IP addressescan lead to an unnecessary “blow-up” in rule-table size.• We study host-registration data for one department-levelnetwork, to understand the dimensions of network policiesand the number and size of host “groups” with these at-tributes. The analysis has important implications for the de-sign of Alpaca.
2.1 Policies on Multiple DimensionsMany universities make descriptions of their high-level
network policies available online (see http://tinyurl.com/pwvlygx for a summary). Most schools classify hosts bythe owner’s role (e.g., faculty, students, staff, visitors), de-partment, residence (e.g., a particular dormitory), and us-age (e.g., research vs. education). In addition, many schoolsassociate each host with a security level (with around tendifferent integer values) and whether the host is currentlyviewed as compromised (with a “yes” or “no” value). Someschools also classify hosts by bandwidth quota and past us-age, to inform rate-limiting policies, and by whether theyoffer core services (e.g., email and web servers). Based onthese documents, and our discussions with the administra-tors of the computer-science department’s network of oneuniversity (University A), we learned about the followingexample policies.
Security: Schools use the security level to limit which ex-ternal users can access a given host (and in what way). Forexample, hosts at the lowest security level might be blockedfrom receiving unsolicited traffic from external hosts; that is,these hosts cannot run public services. Other security levelscorrespond to different restrictions on which transport portnumbers are allowed (e.g., port 80 for HTTP, but not port 22for SSH or 109, 110, and 195 for POP3). Some schools al-low individual departments to state their own access-controllists, applicable only to hosts with IP addresses in that de-partment’s address block. When administrators identify aninternal host as compromised, they change the compromisedattribute and significantly restrict the host’s access to net-work services. In addition, users in the visitor category typ-ically have access to a limited set of services on the campus(e.g., no access to the printers or campus email servers andcompute clusters). One school restricts access to computeclusters in dormitories to the students residing in that partic-ular dorm.
Quality of Service: Some universities impose a differ-ent default bandwidth quota based on the host’s role, but al-low students and postdocs to purchase a higher quota. Someuniversities employ rate-limiting policies that depend on theuser’s bandwidth usage on previous days (e.g., users whosebandwidth usage exceeded a certain level were rate-limitedto a lower level). Hosts offering core services are excludedfrom bandwidth usage calculations for both the users respon-sible for the service machines and the owners of the accessmachines, to avoid that traffic counting against their usagecaps. Also, some schools offer higher quality-of-service forhosts assigned for educational use (e.g., for streaming high-quality media in a classroom). The administrators of Univer-sity A also expressed a desire to perform server load balanc-
ing for internal Web services based on user role, to preventheavy load from one group of users from compromising theperformance of other users.
Administrator “wish-lists”: Our discussions with the ad-ministrators of University A also indicated that there weremany additional policies that they would ideally like to im-plement in the network, but did not do so since they werehard to realize in practice. University A assigns hosts toVLANs based on role (e.g., faculty, staff, and students),for traffic isolation, to prevent packet sniffing and exces-sive broadcast traffic. The administrators would like to applyaccess-control policies based on device usage, device owner-ship, and OS, but do not do so today, since this would requireexhaustive enumeration of IP addresses in the switch config-uration. Likewise, the administrators expressed a desire toapply flexible QoS policies based on (i) the way a deviceis used (e.g., research vs. infrastructure machines) and (ii)whether the host is owned by the department (as opposed toa personal “Bring Your Own Device” host).
Our discussions also revealed additional challenges withfederated network management. The campus network as-signs IP addresses in blocks based on location (e.g., build-ing). This raises challenges in applying security policies thatrestrict access to users affiliated with computer science de-partment. Currently, the policy works correctly for hosts thatare physically in the CS building, since these hosts are as-signed a prefix from the CS subnet. However, when a CSuser works in another building (common for faculty withdual appointments in other departments), the host receives adifferent IP address outside the CS subnet and the user is nolonger able to access the CS resources. While the adminis-trators could conceivably update network configurations dy-namically to reflect the IP addresses that should have access,the management complexity is a deterrent. More generally,federated management would be much easier if network ad-ministrators had concise ways to represent security and QoSpolicies based on host attributes.
2.2 Potential for Concise Rules withACIPs
Existing techniques for assigning IP addresses to hostscan lead to a large numbers of rules in the switches. To quan-tify this problem, we analyzed the access-control policies inrouter configuration files for two university networks (Uni-versity B and University C). Prior work shows that hosts ina network may be partitioned into a small number of policyunits [11]—i.e., a set of hosts that have identical reachabil-ity policies in terms of their communication with the rest ofthe network. Though the number of policy units is small, thenumber of ACL rules to express policy could still be as largeas the square of the number of policy units. Thus, we gobeyond [11], and not only identify policy units, but also cal-culate the number of rules required if ACLs were written interms of policy units rather than the existing IP assignment.
Specifically, we consider two hosts as belonging to thesame source policy unit (SPU) if and only if packets sent bythese hosts to all destinations are treated identically in everyACL across all routers. Likewise, we consider two hosts as
Table 1: Host data for CS department (University A)belonging to the same destination policy unit (DPU) if andonly if packets from all sources to these hosts are treatedidentically in every ACL across all routers. We then computethe total number of rules needed to represent each ACL if itwere more compactly expressed in terms of its source anddestination policy units. Our results show that the number ofACL rules required is much smaller than the product of thesource and destination policy units, and indicates that a smartACIP allocation, which classifies hosts into their SPUs andDPUs efficiently, can potentially offer significant reductionranging from 48% to 98% for ACLs of the two universities(Section 5).
2.3 Diverse Attributes and Group SizesTo better understand the attributes of hosts, we collected
data about the 1491 registered hosts of the CS department ofone university (University A). Each host is associated withseven dimensions of information, as summarized in Table 1.In this network, (i) hosts are assigned to separate VLANsbased on role and (ii) role, security level, and status are con-sidered in access-control policy.
Given the number of attributes in each dimension, hostscould theoretically have 161,280 (i.e., 8× 16× 6× 7×3× 2× 5) combinations of attributes. In practice, only 287unique combinations exist; for example, no visitor has aCS_owned host. In addition, some combinations are muchmore popular than others. One group of hosts—belonging toone Linux-based compute cluster—has 109 members (morethan 7% of all hosts). The large number of attributes and thediversity of group sizes have important implications for ad-dress assignment in Alpaca, which encodes host attributesin the IP address to enable more compact representations ofpolicies.
Consider a naive address allocation scheme that performsBitSegmentation, by (1) concatenating a binary encoding ofthe host attributes along each dimension, where dimensioni with a set of attributes Di requires dlog‖Di‖e bits, and (2)using the remaining bits to distinguish hosts with the sameattributes along all dimensions, requiring dlogXe bits, whereX is the size of the largest group.
The resulting encoding would enable very compact rulesin the switches, using wildcard patterns to match on any at-tribute. However, this solution is impractical, even for thissmall network. Representing the seven dimensions would re-quire 19 bits, and representing the largest group (with 109members) would requires 7 bits, for a total of 26 bits—ahighly inefficient allocation of IP address space.
3. ALPACA OVERVIEW
'+&3 6ZLWFK�GULYHU��H�J���2SHQ)ORZ�
$VVLJQ�,3V ,QVWDOO�UXOHV
$GGUHVV�VSDFH+RVW�LQIR
�GK<><
3ROLFLHV
Figure 1: Use Alpaca in a network.
3.1 ACIP allocation with AlpacaWe present Alpaca, a system that embeds host attributes in
IP addresses to enable compact policies. Figure 1 shows anoverview of the system. Alpaca takes as inputs from the net-work operator the set of policy dimensions, and a databasethat lists the attributes associated with each host. It instructsDHCP servers how to assign IP addresses to hosts based onthe results of Alpaca algorithm. If a host needs to be assigneda new address (e.g., it moves to a new location), the originalattributes along with the new location are used in determin-ing the new IP address. Meanwhile, the switch driver instan-tiates the network policies, which are defined on attributes,by installing match-action processing rules on switches. Al-paca coordinates with the switch driver such that rules cancorrectly classify the IP addresses of hosts to the correspond-ing attributes along different dimensions.
While ACIP allocation enables operators to express poli-cies defined on multiple dimensions with switch rules, Al-paca must adapt to the following constraints:
Switch rule-table sizes: Switches impose hard con-straints on the maximum number of rules to be installed.Therefore, Alpaca should optimize the classification of hostsfor different switch architectures so that the attribute-basedpolicies can be compactly expressed with switch rules thatstay within the rule-table sizes.
Adddress space: IPv4 is widely deployed and likely toremain for the foreseeable future. Many enterprises have 16or fewer bits for public IPv4 address space, or up to 24 bitsfor private IPv4 address space (i.e., 10.0.0.0/8). The lim-ited address space calls for an efficient ACIP allocation thatencodes attributes without wasting IPs. Though the addressspace constraint may be relaxed if IPv6 is fully deployed in anetwork, the allocation still needs to take the size of addressspace into account to correctly represent attributes.
Dynamics: Attributes of a host along any dimension maychange. Alpaca must be able to handle changes in the at-tributes of a host while ensuring that only the IP address ofthat host changes, and that IP addresses of other hosts arenot impacted. Alpaca should also handle (1) addition or re-moval of new attributes in existing dimensions without im-pacting the existing IP address allocation, and (2) additionor removal of dimensions, which is however relatively rareand may require significant changes.
3.2 Problem FormulationGiven an IP address space of W bits, a set U of N hosts
(N ≤ 2W ), a set of M dimensions and the attributes for thehosts along each dimension, an Alpaca algorithm computesan assignment of IPs to individual hosts and M sets of clas-sification rules. Each rule-set corresponds to a dimension. Aclassification rule consists of an address pattern p and an at-tribute a; rule (p,a) means that any host with IP matchingp has attribute a. The classification rules in the same rule-set have disjoint address patterns. An example is shown inFigure 2(a)(b).
The classification rule-sets must be optimized. Considera multi-table switch architecture. We install the rule-sets toclassify source or destination (or both) to the correspondingattributes for the use by following tables. Figure 2(c) showsan example, where the first two tables decide the attributes of“department”and “role” of the source by appending values tometadata, the last table decides to permit or deny the sourcebased on attributes.
Our primary optimization goal is to minimize the totalsizes of M rule-sets, i.e., the number of classification rulesthat decide the attributes of all hosts along all dimensions ina multi-table switch architecture. We also extend our algo-rithms (Section 4.2) to optimize the rules for a single-tableswitch architecture, where the installed rule-set is the prod-uct of all rule-sets in a multi-table architecture (e.g., the threetables in the example) and the total number of installed rulesheavily depends on how frequent attributes (or the combina-tion of attributes) are used in the network policies.
3.3 Overview of Alpaca algorithmsAlpaca consists of a series of algorithms targeted at dif-
with a proven approximation ratio to the optimal case. It usesaddress space efficiently, requiring exactly dlog2Ne bits. It isspecially designed for multi-table switches with SRAMs thatsupport a large number of prefix rules.
The Wildcard algorithm computes wildcard classifica-tion rules. It uses a small address space and can be appliedto single-table and multi-table switch architectures.
Both prefix and wildcard algorithms by themselves do nothandle dynamics and host attribute changes.
The Slack algorithm refines the prefix and wildcard algo-rithms by taking advantage of one more bit in the addressspace for an allocation that works well under dynamics inhost attributes.
4. ALPACA ALGORITHMSIn this section we describe Alpaca algorithms for assign-
ing IPs to individual hosts. The first algorithm is designedfor switch chipsets that allow prefix rules while the secondsolution applies for more general chipsets with tables allow-ing wildcard rules.
4.1 Prefix SolutionThis section presents an address allocation algorithm that
3.2 Problem FormulationGiven an IP address space of W bits, a set U of N hosts
(N 2W ), a set of M dimensions and the attributes for thehosts along each dimension, an Alpaca algorithm computesan assignment of IPs to individual hosts and M sets of clas-sification rules. Each rule-set corresponds to a dimension. Aclassification rule consists of an address pattern p and an at-tribute a; rule (p,a) means that any host with IP matchingp has attribute a. The classification rules in the same rule-set have disjoint address patterns. An example is shown inFigure 2(a)(b).
The classification rule-sets must be optimized. Considera multi-table switch architecture. We install the rule-sets toclassify source or destination (or both) to the correspondingattributes for the use by following tables. Figure 2(c) showsan example, where the first two tables decide the attributes of“department”and “role” of the source by appending values tometadata, the last table decides to permit or deny the sourcebased on attributes.
Our primary optimization goal is to minimize the totalsizes of M rule-sets, i.e., the number of classification rulesthat decide the attributes of all hosts along all dimensions ina multi-table switch architecture. We also extend our algo-rithms (Section 4.2) to optimize the rules for a single-tableswitch architecture, where the installed rule-set is the prod-uct of all rule-sets in a multi-table architecture (e.g., the threetables in the example) and the total number of installed rulesheavily depends on how frequent attributes (or the combina-tion of attributes) are used in the network policies.
3.3 Overview of Alpaca algorithmsAlpaca consists of a series of algorithms targeted at dif-
with a proven approximation ratio to the optimal case. It usesaddress space efficiently, requiring exactly dlog2Ne bits. It isspecially designed for multi-table switches with SRAMs thatsupport a large number of prefix rules.
The Wildcard algorithm computes wildcard classifica-tion rules. It uses a small address space and can be appliedto single-table and multi-table switch architectures.
Both prefix and wildcard algorithms by themselves do nothandle dynamics and host attribute changes.
The Slack algorithm refines the prefix and wildcard algo-rithms by taking advantage of one more bit in the addressspace for an allocation that works well under dynamics inhost attributes.
4. ALPACA ALGORITHMSIn this section we describe Alpaca algorithms for assign-
ing IPs to individual hosts. The first algorithm is designedfor switch chipsets that allow prefix rules while the secondsolution applies for more general chipsets with tables allow-ing wildcard rules.
Input OutputHosts Dept Role Addresses
h1 �h5 CS Faculty 0000, 0001,0010, 0011
0111h6 �h7 CS Students 1010, 1011h8 �h10 EE Faculty 0100, 0101
0110h11 �h16 EE Students 1000, 1001
1100, 11011110, 1111
(a) Address assignment.
OutputDept
p a0111 CS101* CS00** CS0110 EE010* EE100* EE11** EE
(c) Rules on multiple tables to permit CS Students and EE Faculty
Figure 2: Example allocation: W = 4,N = 16,M = 2.
4.1 Prefix SolutionThis section presents an address allocation algorithm that
optimizes the number of prefix rules to represent attributesalong multiple dimensions. It targets at multi-table switch ar-chitectures with IP prefix matching tables. We first introducethe notation, then discuss the optimal solution for a single di-mension and the generalization to multiple dimensions.
We use the following notations when illustrating the algo-rithms. Let a be a dimension and A = {a1,a2, ...} be the setof associated attributes. We view a as a function that mapsevery host to an attribute, i.e., a(x)2A is the attribute of hostx. Let T be an ACIP allocation. We use Ca(T ) to denote theminimum number of rules to represent dimension a . Like-wise, for a set of dimensions D = {a,b , . . .}, CD (T ) repre-sents the total number of rules to present all the dimensionsin D using the allocation T , i.e., CD (T ) = Âf2D Cf (T ). Wedefine opta = minT Ca(T ) and optD = minT CD (T ) to bethe minimum number of rules to represent dimension a andthe set of dimensions, respectively.
A single dimension: We start with the simplest case: as-signing addresses to represent exactly one dimension. Con-sider the dimension Role: each attribute of Role, such as Fac-ulty, Students or Visitors, should have its own set of rules forthe hosts. As a prefix pattern matches a power-of-two num-ber of hosts (e.g., 0*** stands for 8 hosts and 111* stands for2 hosts), one attribute might need several rules. The rules ofdifferent attributes do not overlap, i.e., matches are disjoint.Below, we describe a simple algorithm that finds an optimaladdress allocation to represent one dimension.
Given the dimension function a : U ! A, the algorithmreturns the address allocation function T : U ! {0,1}W .
5
Figure 2: Example allocation: W = 4,N = 16,M = 2.
optimizes the number of prefix rules to represent attributesalong multiple dimensions. It targets at multi-table switch ar-chitectures with IP prefix matching tables. We first introducethe notation, then discuss the optimal solution for a single di-mension and the generalization to multiple dimensions.
We use the following notations when illustrating the algo-rithms. Let α be a dimension and A = {a1,a2, ...} be the setof associated attributes. We view α as a function that mapsevery host to an attribute, i.e., α(x)∈A is the attribute of hostx. Let T be an ACIP allocation. We use Cα(T ) to denote theminimum number of rules to represent dimension α . Like-wise, for a set of dimensions D = {α,β , . . .}, CD (T ) repre-sents the total number of rules to present all the dimensionsin D using the allocation T , i.e., CD (T ) = ∑φ∈D Cφ (T ). Wedefine optα = minT Cα(T ) and optD = minT CD (T ) to bethe minimum number of rules to represent dimension α andthe set of dimensions, respectively.
A single dimension: We start with the simplest case: as-signing addresses to represent exactly one dimension. Con-sider the dimension Role: each attribute of Role, such as Fac-ulty, Students or Visitors, should have its own set of rules forthe hosts. As a prefix pattern matches a power-of-two num-ber of hosts (e.g., 0*** stands for 8 hosts and 111* stands for2 hosts), one attribute might need several rules. The rules ofdifferent attributes do not overlap, i.e., matches are disjoint.Below, we describe a simple algorithm that finds an optimaladdress allocation to represent one dimension.
Given the dimension function α :U→A, the algorithm re-turns the address allocation function T : U → {0,1}W . Thecore idea is to treat the number of hosts for each attributeas the sum of power-of-twos and use a prefix rule for eachpower-of-two. Specifically, we first partition hosts into |A|sets based on their attributes. Let ni be the number of hostswith attribute ai (i = 1, , |A|) and bin(ni) be the binary repre-
sentation of ni. We represent ni as the sum of distinct power-of-twos based on bin(ni). For example, bin(14) = b1110 and14 is represented as 8+ 4+ 2. Next, for each attribute ai,we further partition the set of hosts into subsets accordingto sum representation of ni. For example, if ni = 14, we willpartition the set of hosts into 3 subsets with size 2,4 and 8 re-spectively. The last step is to sort all the subsets for differentattributes in non-increasing sizes. Hosts are ordered basedon the subsets they belong to. The resulting address alloca-tion gives the k-th host address bin(k). The pseudo-code ofthe algorithm is shown in Algorithm 1.
Algorithm 1 Optimal algorithm for a single dimension αfor all attribute ai ∈ A do
Ui = {x ∈U , where α(x) = ai}ni = |Ui|for j = 0 to W do
if 2 j & ni > 0 thenCreate a subset of 2 j hosts selected from UiRemove these 2 j hosts from Ui
end ifend for
end forSort all subsets by their sizes in a non-increasing orderSort hosts according to the order of subsetsAssign k-th host an address of bin(k), k = 0,1, ...,Nreturn the address allocation of hosts
Let ‖bin(ni)‖ be the number of 1s in the binary represen-tation of ni, e.g., ‖bin(14)‖ = 3. The above algorithm con-structs ∑|A|i=1 ‖bin(ni)‖ subsets. We show that the resultingaddress allocation needs exactly ∑|A|i=1 ‖bin(ni)‖ rules for α .In other words, each subset takes a single rule to represent.To prove it, we consider a subset of size 2i. Since subsetsare sorted in non-increasing sizes, any previous subset musthave a size of 2 j for some j ≥ i. Hence, the sum of the sizesof all previous subsets are multiples of 2i. This guaranteesthat all 2i hosts in the current set can be all represented by asingle prefix rule with exactly i wildcards. To prove the op-timality of the algorithm, we further show that an attributeshared by ni hosts requires at least ‖bin(ni)‖ rules.
PROPERTY 1. For a dimension α , let ni = |{x ∈U |α(x)= ai}| be the number of hosts that have to be mappedto an attribute ai, i = 1,2, · · · , |A|. The minimal number ofrules that can represent α in any ACIP allocation satisfiesoptα = minT Cα(T ) = ∑|A|i=1 ‖bin(ni)‖.
Two dimensions: Let α : U → A,β : U → B be the di-mensions under consideration, where B = {b1, · · · ,b|B|} isthe set of attributes in the second dimension. We observe aclear tradeoff between shortening the representation of thesetwo dimensions. While we could choose the address alloca-tion to be the optimal for α and use the minimal number ofrules for α , we may have to use many more rules to representβ . Since the address allocation is shared by both dimensions,in most cases we cannot find an allocation that favors both
dimensions. Below, we show the property on the relation-ship between the optimal allocation for two dimensions andthe optimal allocation for each dimension. We recall that theoptimal allocation minimizes the sum of the number of rulesto represent each dimension.
PROPERTY 2. The optimal allocation for the dimensionsα , β satisfies optα,β ≥ optα + optβ . An equality optα,β =optα + optβ is achieved if there exists an allocation that isoptimal for the dimension α as well as for the dimension β .
To obtain an upper bound on the optimal number of rules,we construct a special allocation below. Let γ be a new di-mension, which is the product of α and β . The correspond-ing set of attributes C = {c1, . . . ,c|A|·|B|}. For a host x ∈U , ifα(x) = ai,β (x) = b j then γ(x) = c(i−1)·|B|+ j. The dimensionγ , denoted by γ = α × β , has the property that γ(x) deter-mines the attributes α(x),β (x) for the same host x. Considerthe representation of γ under some allocation T with Cγ(T )rules. We can obtain a representation of the dimension α (orof β ) with the same number of rules by only modifying theattribute of each rule, i.e., replacing attribute in C with thecorresponding attribute in A (respectively in B). Therefore,Cα(T )≤Cγ(T ), Cβ (T )≤Cγ(T ). Finally,
Cα(T )+Cβ (T ) =Cα,β (T )≤ 2Cγ(T ) (1)
We remark here that these are not necessarily the minimumrepresentations of α,β with the address allocation T : we canfurther compress rules for each dimension.
Next we show that an optimal allocation for γ is a 2-approximation of the optimal allocation for α,β , i.e., thenumber of rules it generates is at most twice of the mini-mum. Consider some allocation T , it must satisfy
Cγ(T )≤Cα(T )+Cβ (T ) =Cα,β (T ) (2)
This is because a group of hosts that cannot be representedusing a single rule in γ must have different attributes in atleast one of α and β , thus requiring a minimum of two rulesto represent in that dimension. Let Tγ be the optimal solu-tion of γ and Tα,β be the optimal solution for α,β together.Substituting T with Tα,β in Equation 1 and 2, we obtain
Meanwhile, since Cα,β (Tα,β ) = optα,β and Cγ(Tα,β ) ≤Cγ(Tγ) = optγ , we conclude the following property:
PROPERTY 3. Let Tγ be an optimal allocation for γ =α×β . Then, Cα,β (Tγ)≤ 2 ·optα,β .
To summarize, for two given dimensions α,β , we calcu-late γ = α×β and find its optimal allocation Tγ by the algo-rithm for a single dimension. We then use this allocation torepresent each of the dimensions α,β .
General number of dimensions: We can generalize theabove solution for two dimensions to handle a set D of anarbitrary number of dimensions M = |D |. Similar to com-puting γ for the two dimensions, we introduce a dimen-sion ΠD , whose attributes for a host x ∈ U is a vector oflength |D | with the attributes of all dimensions in D for that
host. We show that the optimal allocation for ΠD is an M-approximation to the optimal allocation for D . We omit theproof for brevity.
4.2 Wildcard SolutionIn this section, we present an algorithm that generates
wildcard rules by optimizing the output of the prefix solu-tion. To illustrate the algorithm, we use the same examplein Figure 2. For clarity, we use host group to refer the setof hosts with the same attributes along all dimensions; weuse rules and patterns interchangeably to refer the compactACIP representation of host groups and attributes.
We revisit our example. The prefix solution uses 1 pat-tern for the CS Students group and 2 patterns for each of therest groups, because it views the size of a host group as thesum of powers-of-twos (e.g., 5 = 1+4), each of which cor-responds to a prefix pattern. Hence, it uses 2+ 2 = 4 prefixrules to represent Faculty attribute. But if we assign {0111,010*} to EE Faculty and {0110, 11**} to CS Faculty, thenwe can compress these patterns to a single pattern *1** torepresent Faculty attribute. The key observation is that if twohost groups share common attribute(s), it is beneficial to as-sign them similar patterns that can be compressed to reducethe number of rules for the common attribute.
Potential compression. Our first task is to find out all thepotential compression of patterns among host groups. Start-ing with the output of prefix solution, which uses the sum ofpower-of-two terms to denote the size of a host group, wemap every power-of-two term to a node. The node saves thevalue of the term and copies the attributes of the host group.For example, we can create two nodes for the CS Facultygroup: (CS, Faculty, 1) and (CS, Faculty, 4), as the groupsize 5 = 1+4. Figure 3(b) shows the full list of nodes.
Two nodes can be compressed if their values are equal andthey share some common attribute(s). The result of compres-sion is a new node that (1) has a value equal the sum of thevalues of the two nodes, (2) “inherits” the shared attributesand (3) has /0 attributes for other dimensions. For example,(CS, Faculty, 1) and (EE, Faculty, 1) can be compressed intoa new node ( /0, Faculty, 2). We call the new node a super-node and the two original nodes sub-nodes. The compres-sion suggests that we could use the super-node instead oflisting two sub-nodes individually to represent their commonattributes.
A super-node can be compressed with other nodes, as longas they share the same attributes (except /0). But a node can-not be compressed twice on the same dimension, i.e., once
��������)����
����&6��)���� ����((��)���
����((��6����
����((��)��������((��6���� ����&6��6����
����&6��)����
�������)����
��������6����
�����((������� ��������)�����������6����
�����((�������
�T��JG@�T��@KO
Figure 4: The compression graph: a node has an id, at-tributes and a value. Colored nodes are super-nodes.
�D�
�F�
�
� �
��G�
�E�
�
� �
��F�
G�
� �
F�
�
� �
��
�
E�
�
�G�
��
G�
� �
F�
�
� �
��
�
E�
�
Figure 5: Flip bits to compress nodes
(CS, Faculty, 1) and (EE, Faculty, 1) are compressed, nei-ther of them can be compressed with other nodes that haveFaculty attribute. We repeat the compression until no newsuper-nodes can be produced. We plot graphs to denote thecompression relationship by creating edges from sub-nodesto their super-nodes (Figure 4).
In the graph, a node with value 2k can be assigned a wild-card pattern with exactly k wildcards, which represent 2k
hosts. As we work on the output of the prefix solution, theinitial nodes (Figure 3(b)) should be assigned prefix patterns.
Compressible patterns. Two patterns are compressible ifthey negate at exactly one bit, e.g., *00* and *10* are com-pressed into **0*. When two sub-nodes (of a super-node)are assigned compressible patterns (e.g., *00* and *10*), theresulting pattern (e.g., **0*) can be assigned to the super-node to achieve a reduction of one rule in representing thecommon attribute, where we can use the compressed patterninstead of listing two patterns independently. In the exam-ple, we can use the pattern for ( /0, Faculty, 2) to representCS attribute rather than two patterns for (CS, Faculty, 1) and(EE, Faculty, 1). Therefore, our goal is to assign patterns tonodes to maximize the number of pairs of sub-nodes withcompressible patterns, i.e., the total reduction in the numberof rules to represent attributes.
Key idea: flip one bit. Let aibicidi be the pattern as-signed to the i-th node, where ai,bi,ci,di ∈ {0,1,∗}. Con-sider Node 1 (CS, Faculty, 1) and Node 2 (EE, Faculty, 1).a1b1c1d1 and a2b2c2d2 are compressible if they negate at onebit, i.e., a1b1c1d1 = a2b2c2d2, or a2b2c2d2, or a2b2c2d2, ora2b2c2d2. Our key idea to enable compression is to choose abit (e.g., a,b,c or d) to flip. If we flip d, the compressed pat-tern a1b1c1∗ (or a2b2c2∗) can be assigned to the super-node( /0, Faculty, 2), i.e., Node 8. As a result, a8b8c8d8 = a1b1c1∗.We plot the equality in Figure 5(a).
Deptp a
0110 CS001* CS11** CS0111 EE10** EE0*0* EE
Rolep a
*1** Faculty*0** Students
Figure 6: Wildcard rule-sets.
Similarly, we can compress patterns of Node 3 and Node4 by flipping c (d3 = d4 = ∗) as shown in Figure 5(b). We canfurther compress (1) Node 5 and Node 3 by flipping b (as c3is flipped before) and (2) Node 5 and Node 8 by flipping c(shown in Figure 5(c)). However, we are unable to compressNode 6 (a6b6c6d6 = a3b3 ∗∗) and Node 10 (a10b10c10d10 =a3 ∗ c3∗), because their patterns do not match. We finish theprocedure by compressing Node 6 and Node 9, Node 7 andNode 10 (Figure 5(e)). To translate the results to patterns, weset all variables, i.e., a3,b3,c3,d1, to 0.
To summarize, with the idea of bit flipping, we constructequality and inequality between the bits of patterns, i.e.,a,b,c,d, assigned to nodes. For the patterns of each pair ofsub-nodes, if the equality (or inequality) is not determinedbefore, we choose the last possible bit to flip. When thereis no such a bit (i.e., all the patterns negating at one bit arealready used), then we choose to flip more than one bit un-til the resulting patterns do not overlap with any used ones.After checking all the pairs of sub-nodes, we obtain the fullequality and inequality. The final step is to set all free bitvariables to 0.
We can represent each attribute with rules given the pat-tern assignment (Figure 6). For example, to represent Stu-dent, we can use *0** for super-node ( /0, Student, 8), i.e.,Node 12. Similarly, we use 10**, 0*0* and 0111 to repre-sent EE. In total, we need 3+ 3+ 1+ 1 = 8 rules to repre-sent all the attributes, whereas prefix solution needs 9 rules(Figure 2(b)).
In what follows, we discuss the order to process pairs ofsub-nodes (or super-nodes) to achieve the optimization goal,extend the solution to generate prefix rules and how to han-dle weighted attributes to support the single-table switch ar-chitecture (Section 3).
Processing order of sub-nodes. The order we use to pro-cess sub-nodes matters, as the compression of one pair ofsub-nodes may restrict the compression of another (due tothe equality and inequality between bits). The algorithm cal-culates the order values for super-node n as the total num-ber of super-nodes in the tree rooted at n in the graph. Forexample, the tree rooted at ( /0, S, 4) only contains one super-node (i.e., itself); the tree rooted at ( /0, F, 8) contains three.Super-nodes are sorted according to their order values andexamined one by one. When examining one super-node, weprocess all the pairs of sub-nodes in its tree. If the compres-sion failed for one pair (i.e., we cannot find a bit to flip),we roll back all the previous compressions of sub-node pairsin the tree and continue to examine the next super-node inthe sorted list; if the compressions of all pairs of sub-nodessucceed, we remove these sub-nodes from the trees of other
super-nodes, re-calculate order values of the affected super-nodes and sort again.
Extension: minimize prefix rules. Although the abovealgorithm is designed to generate wildcard rules, with a sim-ple trick we could use it to minimize prefix rules as well.The key observation is that wildcard patterns are producedwhen we choose to flip non-trailing bits to compress pat-terns. For example, when compressing nodes a1b1c1∗ anda2b2c2∗, if we choose c1 then the result a1b1 ∗ ∗ is a pre-fix pattern, otherwise the pattern (e.g., a1 ∗ c1∗ or ∗b1c1∗) isa wildcard pattern. Hence, to generate prefix rules, we onlyneed to constrain the algorithm to flip the last non-wildcardbit (e.g., c1 in the pattern a1b1c1∗).
Extension: weighted attributes. The basic algorithmminimizes the total number of rules to represent all the at-tributes. But attributes may not be equally important in thesingle-table switch architecture. For example, Students maybe used more often than Faculty. It is preferred to use fewerrules to represent Students despite the increased number ofrules to represent Faculty. We can extend the wildcard algo-rithm to minimize the total number of rules when attributesare weighted. The intuition is to change how the order valuesof super-nodes are calculated. We introduce the weight of asuper-node as the sum of weights of its non- /0 attributes. Tocalculate the order value of a super-node, instead of countingthe number of super-nodes in its tree, we sum up the weightsof the super-nodes in the tree. The sorting and compressionprocedure remains the same. We can also handle weightedcombinations of attributes (e.g., CS Faculty) with a similarmodification to the calculation of weights and order valuesof super-nodes.
4.3 Handle Changes in Host AttributesOur algorithms proposed so far support address alloca-
tion given the attributes of each host. In practice, attributesof a host may change over time (e.g., the department of thecorresponding user might change), or new attributes may beadded (e.g., a new department may be created). In handlingchanges, a key consideration is ensuring that only the IP ad-dresses of impacted hosts are modified to the extent possible.
We employ two techniques to handle changes in attributes.First, to handle growth in the number of hosts that have a cer-tain attribute, we introduce slack, and budget for more hoststhan actually exist. A straight-forward solution is to provi-sion for a growth in the number of hosts corresponding to agiven attribute by a fixed percentage (e.g., 10%), though in-formation about projected trends could be used when avail-able. For example, a university can estimate the number ofhosts in the coming semester based on the number of newlyadmitted students.
Second, to handle growth in the number of attributes alongeach dimension, we introduce a “ghost” attribute for eachdimension (an additional attributes with which no host iscurrently associated) and decide the group sizes for combi-nations of ghost and real attributes (e.g., the number of hostswith ghost department and Students, or the number of hostswith ghost department and ghost role).
Given the input with slacked group sizes and ghost at-
Table 2: An example of slacktributes, Alpaca algorithms compute ACIP allocation. Whenthe updates only occur for the existing attributes, we changethe addresses of the affected hosts to unused ACIP from thepatterns computed for their new attribute. In the case thatthe provisioned slack of a group is exhausted, we partitionthe address space of the associated ghost groups, whose at-tributes are either ghost attributes or attributes of the ex-hausted group, and allocate part of the space to the exhaustedone. For example, if the ACIPs of (Student, CS) are usedup, we could partition the address space of (Student, Ghost-Dept), (GhostRole, CS) or (GhostRole, GhostDept) and as-sign new space to (Student, CS). When the updates involve anew attribute in one dimension, e.g., Department, we run Al-paca algorithms on the address space for the ghost attributeto split the space into two parts: one for the new attribute andthe other for the ghost attribute. Afterwards, the addresses ofaffected hosts are changed accordingly.
Benefits of slack and ghost attributes. The above twotechniques offer another important advantage: further com-pacting network policies beyond the optimal solution. Con-sider an example where there are 7 CS hosts and 7 EEhosts. Alpaca needs at least 3 rules for each attribute, as7 = 4+2+1 (Section 4.1). With slack, we can round 7 to 8,thus allowing Alpaca to use only 1 rule per attribute. In fact,if we round the group size for every attribute to the nearestpower-of-two upper bound, we at most double the numberof addresses to use. Namely, we use at most one extra bit toencode attributes given the slacked group sizes.
We create extra hosts with “mix-matched” attributes suchthat the number of hosts for every attribute is power-of-two(Algorithm 2). Let pa be the target power-of-two and ga bethe number of hosts for the attribute a. We choose attribute vifrom i-th dimension such that pvi > gvi ,∀i ∈ [1,M], and cre-ate h = mini{pvi − gvi} hosts with attribute v1, ..,vM . Whenall attributes in a dimension reach their target power-of-two(i.e., pa = ga), we use the ghost attribute as default, assum-ing its target power-of-two is infinite. We repeat the proce-dure until all attributes reach their target power-of-two (ex-cept ghost attributes). Consider the example in Table 2. Thenumbers of hosts for CS, Faculty and Students should berounded to 16,8 and 16. We create 2 CS Faculty hosts in thefirst iteration and create 5 CS Students afterwards.
For more complex updates that involve additions of newdimensions, it may be desirable to recompute IP allocationsfrom scratch. However, we make several points. First, suchscenarios are relatively infrequent. We envision that Alpacaalgorithms are run with a conservative set of dimensions,even if some of these dimensions are not currently used as
Algorithm 2 Slack algorithmwhile true do
for all Dimension di dovi = ghost attributefor all Attribute a ∈ di do
if pa > ga thenvi = a
end ifend for
end forif ∀i,vi is ghost attribute then
breakend ifh = min pvi −gvigvi = gvi +h,∀iCreate h hosts with attribute v1, ...,vM
end while
part of network policy. Addition of new dimensions is likelyto happen over long time-scales — operators typically col-lect host attribute information using device registration in-formation filled by owners, and introducing new dimensionswould require new data collection for registered devices.Second, when such scenarios do occur, it is feasible to tem-porarily deal with it by splitting the unused address space ofother dimensions and introducing less compact classificationrules to identify a given set of hosts. Finally, changes in ad-dress allocation can be incrementally handled using DHCP.
4.4 Practical IssuesLayer-3 routing. In Alpaca, we consider L3 routing as
a policy that forwards packets based on the “location” oftheir destinations (e.g., the edge switches of the L3 network).Hence, Location is regarded as one dimension in the ACIPallocation. We can run Alpaca to generate classification rulesfor location dimension, i.e., the rule-set for routing. In somecases, operators may want to pre-assign subnets to the edgeswitches, i.e., the classification rules for Location are pre-determined. Alpaca can work with the requirement as well.The prefix solution naturally decides the prefix patterns forone dimension after another, it can compute the rules giventhe pre-assigned prefixes for Location; the wildcard solutioncan construct the equality and inequality of bits in the pat-terns for nodes based on the Location prefixes first, and makethe later ACIP allocation to comply the prefixes.
Mobility. There are two common solutions to ensure con-nection affinity when hosts move. One approach is to keepthe IPs of end-hosts unchanged and update routing rulesinstead [12]; the other proposes protocols for end-hosts tomaintain connections when both IPs can change [13, 14].While seamless migration is orthogonal to our work, Alpacacan work well with either approach. In the former case, wedo not update Alpaca’s classification results, as the attributesof the host is unchanged except location, and the change oflocation (used by the routing policy) is handled by the pro-posed solution; in the latter case, we can freely assign a new
#ACLs Total #Rules #SPU #DPUUniversity B 13 17868 577 624University C 5027 32401 523 87
Table 3: Network policies of two universities.
ACIP to the host based on its updated attributes (includinglocation).
5. EVALUATIONIn this section, we evaluate Alpaca’s effectiveness in pro-
ducing concise rules under two scenarios: (i) actual policiesin existing networks and (ii) futuristic scenarios where op-erators may express policy along many orthogonal dimen-sions. For existing settings, we evaluate Alpaca using thenetwork configuration files of University B and UniversityC (Section 5.1). For futuristic settings, we use the host at-tribute data obtained from University A (Section 5.2). De-tails of both data-sets were presented in Section 2.
Overall, our results show that Alpaca can reduce the num-ber of rules by 60%−68% and 40%−96% as compared tothe current IP address allocation for multi-table switches andsingle-table switches, respectively. Meanwhile, it has the po-tential to reduce the total number of rules by over an order ofmagnitude as compared to the traditional single dimensionalapproaches (e.g.,VLAN) in futuristic scenario where the pol-icy is expressed on many dimensions. Our experiments fur-ther demonstrate that Alpaca can handle changes in hostsgracefully, with only a small extra number of rules.
Our evaluations explore the performance of both Alpacavariants: Prefix (ALP_PFX) and Wildcard (ALP_WC), andfor comparison purposes we also consider the BitSegmenta-tion scheme (BitSeg). Unless otherwise mentioned, both ourprefix and wildcard algorithms use the algorithm (with pre-fix extension) in Section 4.2 and the extension with slack inSection 4.3 by default. We evaluate the schemes for multi-table and single-table switches. However, our evaluationswith single-table switches is limited to the wildcard algo-rithm, since the prefix algorithm can only be applied to themulti-table architectures with prefix matching tables.
5.1 Benefits with Existing Policies
5.1.1 Alpaca for multi-table switchesWe extract the source and destination policy units (SPUs
and DPUs) from the low-level configuration files for both
0
500
1000
1500
2000
2500
3000
3500
4000
4500
Orig BitSegWC_NS WC PFX_NS PFX
#R
ule
s
(a) Rules 0
5
10
15
20
25
30
35
Orig BitSegWC_NS WC PFX_NS PFX
#B
its
(b) BitsFigure 8: Benefits of slack. BS, WC and PFX denoteWildcard, Prefix and BitSegmentation schemes. NS in-dicates variant without slack.University B and University C, as discussed in Section 2.Table 3 shows the total number of ACL rule-sets, ACL rulesacross rule-sets, and the number of SPUs and DPUs for bothuniversities. Given a pipeline of tables, we install the clas-sification rules that associate a given IP with its appropriateSPU and DPU in the first two tables, and the actual policyaction (e.g., permit or deny) based on the SPUs and DPUs inthe last table. We focus on the number of classification rulesin the first two tables for a given policy, since the last tableis the same in all approaches.
Figure 7(a) compares the number of rules used by (1) theoriginal IP allocation (Orig), (2) BitSeg, (3) ALP_PFX and(4) ALP_WC for University B and University C, respec-tively. The original IP allocation needs the most rules. Bit-Seg takes the least, as it uses one rule for each policy unit.Specifically, the number of rules used by BitSeg equals thenumber of SPUs and DPUs. Both ALP_PFX and ALP_WCperform closely to BitSeg, achieving 68% reduction in ruleconsumption as compared to the original. It confirms thatAlpaca can efficiently encode policy units.
Benefits of slack. We compare the case with and with-out slack operations to show the benefits of trading an ex-tra bit for significant reduction in number of rules. Fig-ure 8(a) presents the reduction in the number of rules forUniversity B. We use NS to indicate running Alpaca with-out slack. While WC_NS (3rd bar) is competitive with otherapproaches, PFX_NS (5th bar) performs slightly worse, giv-ing a reduction of 35.4%. The reasons are two-fold: for onething, prefix patterns fundamentally restrict the potential ofusing fewer rules (as compared to wildcard patterns); for theother, PFX_NS solutions represent the exact group size ofevery combination (i.e., each SPU and DPU pair) withoutany slack. If the group size is not power-of-two, PFX_NS so-
0
200
400
600
800
1000
1200
1400
1600
1800
2000
1 2 3 4 5 6
#R
ule
s
#Dimensions
SingleDim
SD_PFX
SD_WC
ALP_PFX
ALP_WC
(a) Increased #dims (Rules)
0
5
10
15
20
25
30
1 2 3 4 5 6
#B
its
#Dimensions
Opt
BitSeg
ALP/SingleDim/SD_PFX/SD_WC
(b) Increased #dims (Bits)
0
2000
4000
6000
8000
10000
12000
14000
16000
1500 3000 6000 9000 12000 15000
#R
ule
s
#Hosts
SingleDim
SD_PFX
SD_WC
ALP_PFX
ALP_WC
(c) Increased #hostsFigure 9: Encode attributes in addresses.
lutions need many more rules. We bridge the gap by addingslack and rounding group sizes. As a result, PFX offers sim-ilar performance to the optimal (i.e., BitSeg). In the remain-der of the evaluation, we run slack algorithm before IP allo-cation by default.
Moving to the number of bits for encoding (Figure 8(b)),we find BitSeg performs the worst, using as many as 34 bits(more than IPv4!). We calculate the least number of bits thatcan sufficiently number all the hosts (13 for University B).While the original allocation uses the least bits, PFX_NStakes exactly one bit more as the slack algorithm makes useof an extra bit to round group sizes (Section 4.3). Alpacastrikes a balance in both the number of rules and bits, usingalmost as few rules as BitSeg and one extra bit than the leastnumber of bits.
5.1.2 Alpaca for single-table switchesGenerally, a switch with a single table takes more rule
space than the one with multiple tables to implement thesame policy, because the rules installed in the former caseare the cross-product of rules in the multiple tables in thelatter case. Alpaca uses the frequency of attributes (i.e., SPUor DPU) used in ACLs to minimize the resulting rules. Wecompare three approaches: ALP_WC, BitSeg and the orig-inal IP allocation. Figure 7(b)(c) demonstrate the effective-ness of Alpaca in compacting large ACL rule-set. Alpacawildcard compacts the original policies by 40%−96%, com-petitive with BitSeg. We would like to point out that the orig-inal ACLs are written with respect to the resource constraintsof the deployed switches in the networks. As a result, all theoriginal ACLs could fit into the switches. But even so, thereduction by Alpaca is significant. It suggests that with Al-paca, the network operators can use cheaper switches withsmaller rule-tables to support today’s policies, or plan forlarger policies in the future with the current switches.
5.2 Benefits with Futuristic PoliciesWe demonstrate Alpaca’s capability to support flexible
attribute-based policies with a series of experiments on thehost information at the CS department of University A (Ta-ble 1). In the current CS network, operators deploy VLANsto group hosts with the same Role, which is used in mostnetwork policies. But they would like to use Security Level,Status and Operating System for access control and haveflexible QoS policies defined on Usage, CS_owned as well.
Hence, we examine the cost in terms of rules and addressspace to support the futuristic scenarios, where policies aredefined on attributes along multiple dimensions.
We compare Alpaca with three approaches:(1) SingleDim (e.g., VLAN), which assigns addresses
based on a single dimension. SingleDim uses a few rules torepresent attributes for one dimension: VLAN uses one rule(the subnet) for each Role attribute; a host is assigned a ran-dom address in the subnet corresponding to its Role attribute.However, given a second dimension or more, SingleDim hasto enumerate every single host and list their attributes.
(2) SD_PFX, which applies an optimal algorithm [15] tominimize the number of prefix rules for attributes, given theSingleDim address assignment.
(3) SD_WC, which uses an efficient heuristic [16] tocompute the wildcard rules to represent attributes based onthe SingleDim address assignment, as minimizing wildcardrules is NP-hard [17].
We remark that SD_PFX and SD_WC minimize the num-ber of rules by assuming rule priority. Both methods gener-ate overlapping rules for different attributes. In contrast, Al-paca generates non-overlapping rules for different attributes,i.e., does not apply rule priority. Below, we show that evenwithout using rule priority, Alpaca significantly outperformsthe two compression methods.
Scale with more dimensions. We evaluate Alpaca’s en-coding efficiency and scalability with increasing number ofdimensions. Six dimensions are chosen (in order): Role, Se-curity Level, Location, Status, CS_owned and Usage. Theinitial set of dimensions only contains Role. Then, in eachiteration, we add one more dimension to the current set andrun Alpaca algorithms to generate classification rules. Fig-ure 9(a) plots the number of rules generated by SingleDim,SD_PFX and SD_WC and Alpaca over the six iterations.Given one dimension, all approaches generate a small num-ber of rules. Moving to two dimensions (i.e., Role and Se-curity Level), SingleDim has to potentially enumerate hostsand their attributes, taking as many rules as the number ofhosts in the data. The number of rules used by SingleDimis unchanged over the iterations then. SD_PFX and SD_WCgenerates less rules than SingleDim, as they apply compres-sion algorithms for a smaller rule set to represent attributes.Yet, when there are six dimensions, the number of rules(1130 wildcard rules and 1363 prefix rules) is very closeto the number of hosts. In contrast, both Alpaca prefix and
0
20
40
60
80
100
120
140
R,SL,Loc
R,SL,OS
Loc,CS,OS
R,CS,OS
Loc,S,Use
SL,S,CSS,CS,OS
#R
ule
s
ALP_PFX
ALP_WC
(a) Different sets of dims
0
50
100
150
200
PFX_Update WC_Update
#R
ule
s
FirstSet
Overflow
NewAttribute
UnionOfTwoSets
(b) Update assignment
Figure 10: Property of Alpaca algorithm
wildcard scales well with increasing number of dimensions.Alpaca uses 376 wildcard rules or 456 prefix rules for sixdimensions, which are significantly smaller. We show thenumber of bits in Figure 9(b). Both Alpaca and SingleDimapproaches use 12 bits, while the least number of bits (de-noted as Opt) is 11 (1491 < 211). BitSeg is infeasible inpractice after two dimensions, as it takes more than 16 bitsto encode attributes.
Scale with more hosts. Our data only covers a single de-partment, but an entire university (with dozens of depart-ments) has more hosts and enterprises can be even larger insizes. We examine Alpaca’s scalability with more hosts, bysynthesizing the host information. We copy each host 2 to 10times and obtain the scaled-up host data. Figure 9(c) com-pares several approaches to classify hosts in 6 dimensions.Alpaca scales well, using 436 wildcard rules or 528 prefixrules for around 15000 hosts. Its performance is very stable,due to the use of aggregated patterns (e.g., wildcard or pre-fix matches) to classify groups of hosts. The number of hostsdoes not impact its performance. In contrast, SingleDim po-tentially needs 15000 rules to enumerate every host; it doesnot scale to larger networks. The compression algorithms donot help much: SD_PFX and SD_WC need 13589 and 10821rules, respectively, because the single dimension based allo-cation does not help the aggregation on other dimensions.
Encode different sets of dimensions. While Alpaca per-forms well for three dimensions: Role, Security Level andLocation (as shown above), we are curious about its perfor-mance on a different set of three dimensions, such as Role,CS_owned and Operating System. Hence, we fix the num-ber of dimensions to encode and run the algorithm on vari-ous sets of dimensions. Figure 10(a) shows the performanceof Alpaca to encode seven sets of three dimensions. We doobserve the fluctuation: the number of rules generated by Al-paca ranges from 36 to 117 for wildcard case and 44 to 135for prefix case. Upon closer examination, we find out thatthe performance is highly correlated with the possible com-binations of attributes. Specifically, for the set of dimension{Role, Security Level, Location}, there are 80 combinationsof attributes which at least one host is associated with; forthe set {Status, CS_owned, OS}, there are only 22 combi-nations. Given increasing numbers of combinations of at-tributes, Alpaca is more likely to generate many rules.
Update the assignment for new hosts. We divide hostsinto two equal-sized sets based on their created time andrun Alpaca to encode four dimensions: Role, Security Level,Status and Usage. We use the first set for the initial hosts
and the second set for the newly added hosts. For the firstset, Alpaca provisions slack and creates ghost attributes forall dimensions. The second set not only inserts more hostswith the existing attributes but also introduces 4 more newattributes in Security Level. To assign addresses to new hostswith existing attributes, Alpaca uses the slack in the cor-responding group. But if the group size is insufficient, Al-paca has to “stealâAZâAZ flow space from the related ghostgroups (Section 4.3). To handle the new attributes, Alpacasplits the address space of ghost attributes in the same di-mension as well. In our evaluation (Figure 10(b)), the firstset (left red bar) uses 139 prefix rules or 119 wildcard rulesto represent the four dimensions. Fixing the assignment forthe first set, we calculate the extra rules needed to handle thesecond set. The extra rules come from two parts: (1) hostswith new attributes and (2) overflowed group sizes. As a re-sult, we need an extra 6 rules for the new attributes and 24rules for the overflowed groups. The overhead is very smallcompared to 153 prefix rules or 130 wildcard rules for theunion of the two sets, where the assignment is computedfrom scratch without any incremental updates.
6. RELATED WORKRule optimization: Minimizing prefix rules matching one
header field is easy [18], but minimizing prefix rules or wild-card rules in general cases is NP-hard [15, 17]. Optimal so-lutions are developed to minimize prefix rules in specialcases [18–22]. Heuristics [15, 23, 24] are presented to com-press rules in general cases. In particular, [25] suggests todecompose a single rule list into a pipeline of rule lists tominimize the total number of rules. All of these works takethe rule-set as an input and explore the potential for mini-mization, which, in fact, is limited by the original (unopti-mized) address allocation. In comparison, Alpaca generatesthe rule list as an output through a smart address allocationprocess to minimize the number of rules.
Address permutation: Wei et al. propose to swap ad-dresses between two blocks of users to reduce the numberof rules [26], but the algorithm can only handle up to twodimensions. Meiners et al. use permutation of the bits in ad-dresses to create prefix patterns so compression algorithmscan apply [16]. But it only discovers the optimization poten-tial within the original address allocation.
Information encoding: Huffman coding encodes at-tributes of a single dimension using prefixes, but its goal isto minimize the weighted sum of the prefix lengths of allattributes. Hence the prefixes do not match the group sizes.SoftCell [12] embeds two dimensional information, i.e., lo-cation and middlebox service chain, in the NAT-ed IP ad-dresses. Its encoding mechanism is a special case of BitSeg-mentation. Algorithms to encode forwarding rules with min-imum bits are proposed in [27, 28].
Attribute-based policy enforcement: Ethane [3] pro-poses to implement access control at the network edge bydirecting the first packet of every flow to a controller, whichconsults the attributes of hosts and install microflow ruleson the switch. FlowTags [4] tag packets based on host at-
tributes and match tags to enforce network policies. Anotherapproach, NetAssay [29], supports network traffic monitor-ing policies by pushing specific switch-rules for each hostgiven their current IPs. All these work do not optimize IPallocation and install many host-specific rules.
7. CONCLUSIONIn this paper, we have made three contributions. First, we
show the importance and feasibility of considering attributesin IP address allocation. Second, we present the Alpaca sys-tem, and two algorithms which cope well with constraintson the IP address space, enterprise churn, and heterogeneityin group sizes. When evaluated with configuration data fromtwo universities, ALP_WC and ALP_PFX reduce the num-ber of rules by 50%−68% and 60%−68% respectively formulti-table switches. Further, the algorithms have the poten-tial to reduce the total number of rules by over an order ofmagnitude compared to single dimension based IP addressallocation schemes. This can in turn lower the barriers fornetwork administrators to express richer policies involvingmultiple dimensions. While promising, our results are onlya first step. In the future, we hope to build and deploy anactual prototype, as well as evaluate the system with morenetworks and richer data-sets.
8. ACKNOWLEDGMENTWe would like to thank the CoNEXT reviewers and our
shepherd Richard Ma. This work was supported by the NSFgrant TC-1111520 and the NSF Career Award No.0953622.
9. REFERENCES[1] M. Yu, J. Rexford, X. Sun, S. G. Rao, and N. Feamster, “A
survey of virtual LAN usage in campus networks,” IEEECommunications Magazine, vol. 49, no. 7, pp. 98–103, 2011.
[2] “Production quality, multilayer open virtual switch.”http://openvswitch.org/.
[3] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. Gude,N. McKeown, and S. Shenker, “Rethinking enterprisenetwork control,” IEEE/ACM Trans. Netw., vol. 17, no. 4,pp. 1270–1283, 2009.
[4] S. K. Fayazbakhsh, L. Chiang, V. Sekar, M. Yu, and J. C.Mogul, “Enforcing Network-Wide Policies in the Presenceof Dynamic Middlebox Actions using FlowTags,” in NSDI,2014.
[5] N. McKeown, T. Anderson, H. Balakrishnan, G. M. Parulkar,L. L. Peterson, J. Rexford, S. Shenker, and J. S. Turner,“OpenFlow: enabling innovation in campus networks,” ACMSIGCOMM CCR, vol. 38, no. 2, pp. 69–74, 2008.
[6] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown,J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat,G. Varghese, and D. Walker, “P4: Programmingprotocol-independent packet processors,” ACM SIGCOMMCCR, vol. 44, no. 3, pp. 87–95, 2014.
[7] P. Bosshart, G. Gibb, H.-S. Kim, G. Varghese, N. McKeown,M. Izzard, F. Mujica, and M. Horowitz, “Forwardingmetamorphosis: Fast programmable match-action processingin hardware for SDN,” in ACM SIGCOMM, 2013.
[9] M. Appelman and M. D. Boer, “Performance analysis ofOpenFlow hardware,” tech. rep., University of Amsterdam,
Feb 2012.http://www.delaat.net/rp/2011-2012/p18/report.pdf.
[10] D. Y. Huang, K. Yocum, and A. C. Snoeren, “High-fidelityswitch models for software-defined network emulation,” inACM HotSDN, 2013.
[11] T. Benson, A. Akella, and D. A. Maltz, “Mining policiesfrom enterprise network configuration,” in ACM IMC, 2009.
[12] X. Jin, L. E. Li, L. Vanbever, and J. Rexford, “SoftCell:Scalable and flexible cellular core network architecture,” inACM CoNEXT, 2013.
[13] P. Zave and J. Rexford, “The design space of networkmobility,” in Recent Advances in Networking. ACMSIGCOMM, 2013.
[14] E. Nordström, D. Shue, P. Gopalan, R. Kiefer, M. Arye,S. Ko, J. Rexford, and M. J. Freedman, “Serval: An end-hoststack for service-centric networking,” in USENIX NSDI,2012.
[15] C. R. Meiners, A. X. Liu, and E. Torng, “TCAM Razor: Asystematic approach towards minimizing packet classifiers inTCAMs,” IEEE/ACM Trans. Netw., vol. 18, pp. 490–500,Apr 2010.
[16] C. R. Meiners, A. X. Liu, and E. Torng, “Bitweaving: Anon-prefix approach to compressing packet classifiers inTCAMs,” IEEE/ACM Trans. Netw., vol. 20, pp. 488–500,Apr 2012.
[17] R. McGeer and P. Yalagandula, “Minimizing rulesets forTCAM implementation,” in IEEE INFOCOM, 2009.
[18] R. Draves, C. King, S. Venkatachary, and B. Zill,“Constructing optimal IP routing tables,” in IEEEINFOCOM, 1999.
[19] S. Suri, T. Sandholm, and P. R. Warkhede, “Compressingtwo-dimensional routing tables,” Algorithmica, vol. 35,no. 4, pp. 287–300, 2003.
[20] D. L. Applegate, G. Calinescu, D. S. Johnson, H. Karloff,K. Ligett, and J. Wang, “Compressing rectilinear picturesand minimizing access control lists,” in ACM-SIAM SODA,pp. 1066–1075, 2007.
[21] O. Rottenstreich and I. Keslassy, “On the code length ofTCAM coding schemes,” in IEEE ISIT, 2010.
[22] O. Rottenstreich, I. Keslassy, A. Hassidim, H. Kaplan, andE. Porat, “Optimal In/Out TCAM encodings of ranges,”IEEE/ACM Trans. Netw., 2015.
[23] K. Kogan, S. I. Nikolenko, O. Rottenstreich, W. Culhane,and P. Eugster, “Exploiting order independence for scalableand expressive packet classification,” IEEE/ACM Trans.Netw., 2015.
[24] O. Rottenstreich and J. Tapolcai, “Lossy compression ofpacket classifiers,” in ACM/IEEE ANCS, 2015.
[25] C. R. Meiners, A. X. Liu, E. Torng, and J. Patel, “Split:Optimizing space, power, and throughput for TCAM-basedclassification,” in ACM/IEEE ANCS, 2011.
[26] R. Wei, Y. Xu, and H. J. Chao, “Block permutations inboolean space to minimize TCAM for packet classification,”in IEEE INFOCOM, 2012.
[27] O. Rottenstreich, M. Radan, Y. Cassuto, I. Keslassy, C. Arad,T. Mizrahi, Y. Revah, and A. Hassidim, “Compressingforwarding tables for datacenter scalability,” IEEE Journalon Selected Areas in Communications (JSAC), vol. 32, no. 1,pp. 138 – 151, 2014.
[28] O. Rottenstreich, A. Berman, Y. Cassuto, and I. Keslassy,“Compression for fixed-width memories,” in IEEE ISIT,2013.
[29] S. Donovan and N. Feamster, “NetAssay: Providing newmonitoring primitives for network operators,” in ACMHotNets, 2014.
