1270 IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 17, NO. 4, AUGUST 2009
Rethinking Enterprise Network Control
Martín Casado, Student Member, IEEE, Michael J. Freedman, Member, IEEE, Justin Pettit, Jianying Luo,
Natasha Gude, Nick McKeown, Fellow, IEEE, and Scott Shenker, Fellow, IEEE
Abstract—This paper presents Ethane, a new network archi-
tecture for the enterprise. Ethane allows managers to define a
single network-wide fine-grain policy and then enforces it directly.
Ethane couples extremely simple flow-based Ethernet switches
with a centralized controller that manages the admittance and
routing of flows. While radical, this design is backwards-com-
patible with existing hosts and switches. We have implemented
Ethane in both hardware and software, supporting both wired
and wireless hosts. We also show that it is compatible with existing
high-fanout switches by porting it to popular commodity switching
chipsets. We have deployed and managed two operational Ethane
networks, one in the Stanford University Computer Science
Department supporting over 300 hosts, and another within a
small business of 30 hosts. Our deployment experiences have
significantly affected Ethane’s design.
Index Terms—Architecture, management, network, security.
I. INTRODUCTION
E NTERPRISE networks are often large, run a wide varietyof applications and protocols, and typically operate under
strict reliability and security constraints; thus, they represent a
challenging environment for network management. The stakes
are high, as business productivity can be severely hampered by
network misconfigurations or break-ins. Yet, the current solu-
tions are weak, making enterprise network management both
expensive and error-prone. Indeed, most networks today require
substantial manual configuration by trained operators [1]–[4]
to achieve even moderate security [5]. A Yankee Group report
found that 62% of network downtime in multivendor networks
comes from human error and that 80% of IT budgets is spent on
maintenance and operations [6].
There have been many attempts to make networks more
manageable and more secure. One approach introduces propri-
etary middleboxes that can exert their control effectively only
if placed at network choke-points. If traffic accidentally flows
(or is maliciously diverted) around the middlebox, the network
Manuscript received May 19, 2008; approved by IEEE/ACM TRANSACTIONS
ON NETWORKING Editor N. Taft. First published July 21, 2009; current version
published August 19, 2009. This work was supported in part by the National
Science Foundation under Grant CNS-0627112 (The 100 100 Clean Slate
Program), by the FIND Program with funding from DTO, and by the Stanford
Clean Slate Program. M. Casado was supported by a DHS graduate fellowship.
M. Casado, J. Pettit, J. Luo, N. Gude, and N. McKeown are with Stanford
University, Stanford, CA 94305 USA (e-mail: casado@cs.stanford.edu;
jpettit@cs.stanford.edu; jyluo@stanford.edu; ngude@cs.stanford.edu;
nickm@stanford.edu).
M. J. Freedman is with Princeton University, Princeton, NJ 08544 USA
(e-mail: mfreed@cs.princeton.edu).
S. Shenker is with the University of California, Berkeley, Berkeley, CA 94720
USA (e-mail: shenker@icsi.berkeley.edu).
Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org.
Digital Object Identifier 10.1109/TNET.2009.2026415
is no longer managed nor secure [3]. Another approach is to
add functionality to existing networks—to provide tools for
diagnosis; to offer controls for VLANs, access-control lists, and
filters to isolate users; to instrument the routing and spanning
tree algorithms to support better connectivity management; and
then to collect packet traces to allow auditing. This can be done
by adding a new layer of protocols, scripts, and applications
[7], [8] that help automate configuration management in order
to reduce the risk of errors. However, these solutions hide the
complexity and do not reduce it. Also, they have to be con-
stantly maintained to support the rapidly changing and often
proprietary management interfaces exported by the managed
elements.
Rather than building a new layer of complexity on top of the
network, we explore the question: How could we change the en-
terprise network architecture to make it more manageable? Our
answer is embodied in the architecture we describe here, called
Ethane. Ethane is built around three fundamental principles that
we feel are important to any network management solution:
The network should be governed by policies declared over
high-level names. Networks are most easily managed in terms
of the entities we seek to control—such as users, hosts, and ac-
cess points—rather than in terms of low-level and often dynam-
ically allocated addresses. For example, it is convenient to de-
clare which services a user is allowed to use and to which ma-
chines they can connect.
Network routing should be policy-aware. Network policies
dictate the nature of connectivity between communicating enti-
ties and, therefore, naturally affect the paths that packets take.
This is in contrast to today’s networks in which forwarding and
filtering use different mechanisms rather than a single integrated
approach.
A policy might require packets to pass through an interme-
diate middlebox; for example, a guest user might be required to
communicate via a proxy, or the user of an unpatched operating
system might be required to communicate via an intrusion-de-
tection system. Policy may also specify service priorities for
different classes of traffic. Traffic can receive more appropriate
service if its path is controlled; directing real-time communica-
tions over lightly loaded paths, important communications over
redundant paths, and private communications over paths inside
a trusted boundary would all lead to better service.
The network should enforce a strong binding between a
packet and its origin. Today, it is notoriously difficult to reli-
ably determine the origin of a packet: Addresses are dynamic
and change frequently, and they are easily spoofed. The loose
binding between users and their traffic is a constant target for at-
tacks in enterprise networks. If the network is to be governed by
a policy declared over high-level names (e.g., users and hosts),
then packets should be identifiable, without doubt, as coming
1063-6692/$26.00 © 2009 IEEE