From: Ben Pfaff Date: Mon, 14 Jan 2013 07:19:32 +0000 (-0800) Subject: Describe dummy test model. Work on OpenFlow intro. X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=5ae71bb591b4d60f723faa4fbace13eef2b07b02;p=openvswitch Describe dummy test model. Work on OpenFlow intro. --- diff --git a/doc/manual.texi b/doc/manual.texi index a303efef..79329e19 100644 --- a/doc/manual.texi +++ b/doc/manual.texi @@ -9,7 +9,7 @@ Open@tie{}vSwitch @end macro @copying -Copyright @copyright{} 2012 Nicira, Inc. +Copyright @copyright{} 2012, 2013 Nicira, Inc. Licensed under the Apache License, Version 2.0 (the ``License''); you may not use this file except in compliance with the License. You may @@ -87,7 +87,7 @@ and how they interact with each other and with components not part of Open vSwitch. The most important component of Open vSwitch is the virtual switch -daemon, @program{ovs-vswitchd}. This daemon implements Open vSwitch +daemon, @command{ovs-vswitchd}. This daemon implements Open vSwitch core switching and programmability functions. In a software switch, this daemon is a ``soft real-time'' component that handles the first packet of each new flow that enters the network. In a hardware @@ -96,13 +96,13 @@ features. The virtual switch daemon has two important external interfaces. The first of these speaks a protocol called OVSDB to the second major Open -vSwitch daemon, the @program{ovsdb-server} database server. This +vSwitch daemon, the @command{ovsdb-server} database server. This daemon's configuration database tracks typically slowly changing management plane state, such as the set of configured switches and their ports. The database server can also talk to controllers on remote servers over the same OVSDB protocol. -@program{ovs-vswitchd}'s other major external interface is the control +@command{ovs-vswitchd}'s other major external interface is the control plane interface. This interface allows controllers on remote servers to directly control the treatment of packets that arrive on the switches configured in the database. Control can be reactive, with @@ -113,18 +113,18 @@ some combination. Open vSwitch uses the OpenFlow protocol for this control plane interface. Open vSwitch also includes a number of utility programs. -@program{ovs-vsctl} is an interactive command-line interface to -@program{ovsdb-server} for configuring and querying Open vSwitch +@command{ovs-vsctl} is an interactive command-line interface to +@command{ovsdb-server} for configuring and querying Open vSwitch configuration. It is also used heavily in shell scripts that integrate Open vSwitch with hypervisor and cloud management systems. -@program{ovs-ofctl} is a command-line tool that speaks the OpenFlow -protocol. Unlike @program{ovs-vsctl}, which is often used in +@command{ovs-ofctl} is a command-line tool that speaks the OpenFlow +protocol. Unlike @command{ovs-vsctl}, which is often used in production, it is most useful for troubleshooting and prototyping. We will often use it in examples in this book. -@program{ovs-appctl} is a command-line tool to send commands to -@program{ovs-vswitchd} and @program{ovsdb-server}. It is occasionally +@command{ovs-appctl} is a command-line tool to send commands to +@command{ovs-vswitchd} and @command{ovsdb-server}. It is occasionally useful for special purposes, especially in testing and debugging. @node Testing @@ -181,7 +181,7 @@ hardware and at the same time, it is easier to replicate virtual environments, so taken together it becomes cheaper to run multiple tests in parallel. -A virtual environment doesn't perfectly reproduced the performance of +A virtual environment doesn't perfectly reproduce the performance of the physical environment that it models. A virtual environment usually performs slightly worse than the corresponding physical setup, so one may assume that, if the performance of the virtual model is @@ -208,9 +208,9 @@ possible to ``factor'' the model so that a simple virtualization setup still adequately models the physical setup. For example, one might decide that how virtual machines are assigned to physical hypervisors is not an important characteristic of the physical environment, so -that one may model these virtual machines of the physical environment -as virtual machines in the test model, leaving the hypervisors of the -physical environment out of the model. +that one may represent these virtual machines of the physical +environment as virtual machines in the test model, leaving the +hypervisors of the physical environment out of the model. In situations where factoring the physical hypervisors out of the test model is not acceptable, one may resort to @dfn{nested @@ -227,10 +227,68 @@ setup in a virtual environment that includes nested hypervisors. @node Dummy Test Models @section Dummy Test Models - - -@node outline - +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 * Test setups. ** Physical ** Virtual @@ -298,6 +356,8 @@ exit 0 ** Policing. ** QoS. +** How to simulate NORMAL with rules that don't use it. + * Control plane programming techniques. ** Resubmit. ** Registers. @@ -334,6 +394,35 @@ exit 0 ** Minimizing lookups. ** Minimizing flow table changes. *** Avoiding timeouts. +@end verbatim + +@node Glossary +@unnumbered Glossary + +@macro glentry{term} +@item \term\ +@cindex \term\ +@anchor{\term\} +@end macro + +@table @b +@glentry{action} + +@glentry{bridge} +@xref{switch}. + +@glentry{flow table} + +@glentry{network device} +A real or simulated Ethernet interface. @samp{lo}, @samp{eth0}, and +@samp{wlan0} are common names for network devices under the Linux +kernel. + +@glentry{match} + +@glentry{switch} +An Ethernet switch, also called a ``bridge.'' +@end table @node Index @unnumbered Index