1. THE NEED FOR PROGRAMMABLE
NETWORKS
Networks have become part of the critical infrastructure
of our businesses, homes and schools. This success has been
both a blessing and a curse for networking researchers; their
work is more relevant, but their chance of making an im-
pact is more remote. The reduction in real-world impact of
any given network innovation is because the enormous in-
stalled base of equipment and protocols, and the reluctance
to experiment with production traffic, which have created an
exceedingly high barrier to entry for new ideas. Today, there
is almost no practical way to experiment with new network
protocols (e.g., new routing protocols, or alternatives to IP)
in sufficiently realistic settings (e.g., at scale carrying real
traffic) to gain the confidence needed for their widespread
deployment. The result is that most new ideas from the net-
working research community go untried and untested; hence
the commonly held belief that the network infrastructure has
“ossified”.
Having recognized the problem, the networking commu-
nity is hard at work developing programmable networks,
such as GENI [1] a proposed nationwide research facility
for experimenting with new network architectures and dis-
tributed systems. These programmable networks call for
programmable switches and routers that (using virtualiza-
tion) can process packets for multiple isolated experimen-
tal networks simultaneously. For example, in GENI it is
envisaged that a researcher will be allocated a slice of re-
sources across the whole network, consisting of a portion
of network links, packet processing elements (e.g. routers)
and end-hosts; researchers program their slices to behave as
they wish. A slice could extend across the backbone, into
access networks, into college campuses, industrial research
labs, and include wiring closets, wireless networks, and sen-
sor networks.
Virtualized programmable networks could lower the bar-
rier to entry for new ideas, increasing the rate of innovation
in the network infrastructure. But the plans for nationwide
facilities are ambitious (and costly), and it will take years
for them to be deployed.
This whitepaper focuses on a shorter-term question closer
to home: As researchers, how can we run experiments in
our campus networks? If we can figure out how, we can
start soon and extend the technique to other campuses to
benefit the whole community.
To meet this challenge, several questions need answering,
including: In the early days, how will college network admin-
istrators get comfortable putting experimental equipment
(switches, routers, access points, etc.) into their network?
How will researchers control a portion of their local net-
work in a way that does not disrupt others who depend on
it? And exactly what functionality is needed in networkACM SIGCOMM Computer Communication Review 69 Volume 38, Number 2, April 2008
switches to enable experiments? Our goal here is to propose
a new switch feature that can help extend programmability
into the wiring closet of college campuses.
One approach - that we do not take - is to persuade
commercial “name-brand” equipment vendors to provide an
open, programmable, virtualized platform on their switches
and routers so that researchers can deploy new protocols,
while network administrators can take comfort that the
equipment is well supported. This outcome is very unlikely
in the short-term. Commercial switches and routers do not
typically provide an open software platform, let alone pro-
vide a means to virtualize either their hardware or software.
The practice of commercial networking is that the standard-
ized external interfaces are narrow (i.e., just packet forward-
ing), and all of the switch’s internal flexibility is hidden. The
internals differ from vendor to vendor, with no standard
platform for researchers to experiment with new ideas. Fur-
ther, network equipment vendors are understandably ner-
vous about opening up interfaces inside their boxes: they
have spent years deploying and tuning fragile distributed
protocols and algorithms, and they fear that new experi-
ments will bring networks crashing down. And, of course,
open platforms lower the barrier-to-entry for new competi-
tors.
A few open software platforms already exist, but do not
have the performance or port-density we need. The simplest
example is a PC with several network interfaces and an op-
erating system. All well-known operating systems support
routing of packets between interfaces, and open-source im-
plementations of routing protocols exist (e.g., as part of the
Linux distribution, or from XORP [2]); and in most cases it
is possible to modify the operating system to process packets
in almost any manner (e.g., using Click [3]). The problem,
of course, is performance: A PC can neither support the
number of ports needed for a college wiring closet (a fanout
of 100+ ports is needed per box), nor the packet-processing
performance (wiring closet switches process over 100Gbits/s
of data, whereas a typical PC struggles to exceed 1Gbit/s;
and the gap between the two is widening).
Existing platforms with specialized hardware for line-rate
processing are not quite suitable for college wiring clos-
ets either. For example, an ATCA-based virtualized pro-
grammable router called the Supercharged PlanetLab Plat-
form [4] is under development at Washington University,
and can use network processors to process packets from
many interfaces simultaneously at line-rate. This approach
is promising in the long-term, but for the time being is tar-
geted at large switching centers and is too expensive for
widespread deployment in college wiring closets. At the
other extreme is NetFPGA [5] targeted for use in teaching
and research labs. NetFPGA is a low-cost PCI card with
a user-programmable FPGA for processing packets, and 4-
ports of Gigabit Ethernet. NetFPGA is limited to just four
network interfaces—insufficient for use in a wiring closet.
Thus, the commercial solutions are too closed and inflex-
ible, and the research solutions either have insufficient per-
formance or fanout, or are too expensive. It seems unlikely
that the research solutions, with their complete generality,
can overcome their performance or cost limitations. A more
promising approach is to compromise on generality and to
seek a degree of switch flexibility that is:
• Amenable to high-performance and low-cost imple-
mentations.
Controller
OpenFlow
Switch
Flow
Table
Flow
Table
Secure
Channel
Secure
Channel PC
OpenFlow
Protocol
SSL
hw
sw
Scope of OpenFlow Switch Specification
Figure 1: Idealized OpenFlow Switch. The Flow
Table is controlled by a remote controller via the
Secure Channel.
• Capable of supporting a broad range of research.
• Assured to isolate experimental traffic from production
traffic.
• Consistent with vendors’ need for closed platforms.
This paper describes the OpenFlow Switch—a specifica-
tion that is an initial attempt to meet these four goals.

===

Convert this into an introduction to "Software-Defined Wallets" for the cryptocurrency industry. Format it correctly.