From 493dba394fc6886184a28d2f0e1ab4e12a3c6188 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Sat, 8 Dec 2012 10:18:46 -0800 Subject: [PATCH] work --- doc/manual.texi | 152 ++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 140 insertions(+), 12 deletions(-) diff --git a/doc/manual.texi b/doc/manual.texi index 16627389..969d4dd9 100644 --- a/doc/manual.texi +++ b/doc/manual.texi @@ -24,7 +24,7 @@ permissions and limitations under the License. @end copying @titlepage -@title Open vSwitch Guide +@title Programming the Open vSwitch Platform @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. -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 @@ -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. -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 -- 2.30.2