work

diff --git a/doc/manual.texi b/doc/manual.texi
index 166273892b5da319495e785727d72493f25e5ad7..969d4dd93fd2926442d3997c4bed4135003d26d1 100644 (file)
--- a/doc/manual.texi
+++ b/doc/manual.texi
@@ -24,7 +24,7 @@ permissions and limitations under the License.
 @end copying
 
 @titlepage
 @end copying
 
 @titlepage

-@title Open vSwitch Guide
+@title Programming the Open vSwitch Platform

 @author Open vSwitch Contributors
 
 @page
 @author Open vSwitch Contributors
 
 @page


@@ -55,13 +55,13 @@ platform to open up network forwarding to programmatic extension, so
 it really shines in environments that demand fast, flexible control
 over the network.
 
 it really shines in environments that demand fast, flexible control
 over the network.
 

-The most common uses of Open vSwitch today deploy it as a
-software-based switch, that is, on general-purpose computers without
-hardware specialized for switching.  Within this class of uses, Open
-vSwitch is most often used on virtual server hosts, to forward traffic
-among virtual machines and to and from a physical network.
-Virtualization is not a requirement: Open vSwitch can also forward
-traffic among physical interfaces in a ``bare metal'' environment.
+Open vSwitch is most often deployed today as a purely software switch,
+that is, on computers without hardware specialized for packet
+switching.  In this class of uses, Open vSwitch most often runs on
+virtual server hosts, to forward virtual machine network traffic to
+and from a physical network.  Virtualization is not a requirement:
+Open vSwitch can also forward traffic among physical interfaces in a
+``bare metal'' environment.

 
 Open vSwitch is designed and internally layered to be amenable for use
 within special-purpose switch hardware, and a number of network
 
 Open vSwitch is designed and internally layered to be amenable for use
 within special-purpose switch hardware, and a number of network


@@ -70,11 +70,139 @@ Open vSwitch to control high-performance hardware switches as well as
 software switches, although hardware is inherently less flexible than
 software.
 
 software switches, although hardware is inherently less flexible than
 software.
 

-What platforms?  What hypervisors?
-Why OVS?
-What is OpenFlow?
+Open vSwitch runs on top of a wide variety of hardware, operating
+systems, and hypervisors, and it has been integrated with multiple
+cloud management systems.  Please refer to other Open vSwitch and
+vendor documentation for details.

 
 

-@node 
+@menu
+* Architecture::                
+@end menu
+
+@node Architecture
+@section Architecture
+
+This section describes the components of Open vSwitch at a high-level
+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
+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
+switch, it instead configures the hardware's packet processing
+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
+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
+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
+the controller deciding what should be done for each new flow as it
+arrives at the switch, or proactive, with the controller specifying in
+advance the treatment of every packet that might happen to arrive, or
+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
+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
+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
+useful for special purposes, especially in testing and debugging.
+
+@node outline
+
+* Test setups.
+** Physical
+** Virtual
+** Nested virtual
+** Dummy-based.
+** test-vm based
+
+* Test techniques.
+** ofproto/trace
+
+* Introduction to OpenFlow.
+* Packet processing pipeline.
+** The ``normal'' action's pipeline.
+
+* Management plane.
+** Ports and interfaces.
+** Bonding.
+*** How to use through OpenFlow, and limitations.
+*** Future directions.
+*** How to emulate with OpenFlow?
+** VLANs.
+*** Interaction with OpenFlow.
+** MAC learning.
+*** Reading and flushing the MAC learning table.
+*** Preventing MAC learning.
+*** Interaction with bonding.
+*** 
+** Mirrors.
+*** Limitations with OpenFlow.
+*** How to emulate with OpenFlow (avoiding duplicates).
+** Spanning tree.
+*** Limitations for nonstandard setups.
+** CFM
+*** Tradeoffs.
+*** Caveats.
+** Policing.
+** QoS.
+
+* Control plane programming techniques.
+** Resubmit.
+** Registers.
+*** NAND gate.
+** Local controller.
+
+* Proactive control plane programming.
+** Resubmit.
+*** Firewall with ingress and egress rules.
+**** Handling IP fragments.
+** Learning.
+*** A MAC-learning switch.
+**** Reading and flushing the MAC learning table.
+**** Monitoring changes to the MAC learning table.
+*** Stateful firewall.
+** VXLAN control plane.
+** Routing.
+** Spoof prevention.
+*** IPv6.
+** PVLAN.
+
+* Reactive control plane programming?
+** In-band control as example?
+
+* In-band control.
+** How it works.
+** Limitations.
+** Rolling your own.
+
+* Optimization.
+** Separate tables.
+*** Tables with a single type of flow (see learning).
+** Minimizing types of flows.
+** Minimizing lookups.
+** Minimizing flow table changes.
+*** Avoiding timeouts.

 
 @node Index
 @unnumbered Index
 
 @node Index
 @unnumbered Index