+Open vSwitch has a few special ``dummy'' features for testing
+purposes. A @dfn{dummy switch} is an Open vSwitch switch that it
+simulates entirely within itself, without connecting to any physical
+or virtual hardware. Typically a dummy switch's ports will be
+populated with dummy network devices, which are, similarly, simulated
+entirely within @command{ovs-vswitchd}.
+
+A ``dummy test model,'' that is, a test model based on Open vSwitch
+dummy switches, requires no virtual or physical hardware, no
+supervisor privilege, and runs comfortably with minimal memory and CPU
+resources. However, dummy test models do not realistically model
+actual traffic patterns or performance. They also rely on Open
+vSwitch features that are subject to change from release to release.
+
+A unique advantage of dummy test models is that they can run faster
+than real time: the user can manipulate a dummy switch's idea of the
+current time can, causing it to stop or to jump forward an arbitrary
+amount. This can be invaluable for some purposes, such as testing
+flow expiration or NetFlow traffic.
+
+@node Introduction to OpenFlow
+@chapter Introduction to OpenFlow
+
+Programming an Open vSwitch software switch requires a solid grasp of
+the fundamentals of OpenFlow.
+
+An OpenFlow switch has two important parts. The first part is the
+switch's set of ports, which are the same as the ports in any other
+Ethernet switch. The second piece is a set of one or more @dfn{flow
+tables}. A flow table amounts to a set of if-then rules that tell the
+switch how to handle any packet that might arrive at a port. Each
+rule, called a @dfn{flow}, specifies a condition (the @dfn{match}) and
+a list of @dfn{actions} to execute if the condition is met.
+
+To illustrate the idea of a flow table, consider a OpenFlow switch
+with three ports, numbered 1, 2, and 3. The flow table described
+informally below would cause such a switch to act as a ``hub'' that
+forwards each arriving packet to the other two ports:
+
+@quotation
+If the packet arrived on port 1, forward it to ports 2 and 3; @*
+If the packet arrived on port 2, forward it to ports 1 and 3; @*
+If the packet arrived on port 3, forward it to ports 1 and 2.
+@end quotation
+
+In this example, any packet would match exactly one flow. OpenFlow
+provides for packets possibly matching multiple flows on by requiring
+the user to associate each flow with a numeric @dfn{priority}. If a
+packet matches more than one flow, the priority is used as a
+tie-breaker, with the higher priority wins. (If two matching flows
+have the same priority, the behavior is undefined, so flow tables are
+designed to avoid this possibility.)
+
+In some flow tables, some packets match no flows at all. The user can
+configure an OpenFlow switch either to drop these packets or to
+forward them to an OpenFlow controller (describe later) for further
+processing.
+
+@node Outline
+@chapter Outline
+
+@verbatim