@end copying
@titlepage
-@title Open vSwitch Guide
+@title Programming the Open vSwitch Platform
@author Open vSwitch Contributors
@page
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
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
projects / openvswitch / commitdiff