WHY-OVS: New file explaining the rationale for Open vSwitch.

Signed-off-by: Martin Casado <[email protected]>
Signed-off-by: Paul Fazzone <[email protected]>
Signed-off-by: Dan Wendlandt <[email protected]>

Makefile.am

@@ -43,6 +43,7 @@ EXTRA_DIST = \
 	README-gcov \
 	REPORTING-BUGS \
 	SubmittingPatches \
+	WHY-OVS \
 	boot.sh
 bin_PROGRAMS =
 sbin_PROGRAMS =

WHY-OVS

@@ -0,0 +1,104 @@
+                          Why Open vSwitch?
+                          =================
+
+We love the existing network stack in Linux.  It is robust, flexible,
+and feature rich.  Linux already contains an in-kernel L2 switch (the
+Linux bridge) which can be used by VMs for inter-VM communication.  So,
+it is reasonable to ask why there is a need for a new network switch.
+
+The answer is that Open vSwitch is targeted at multi-server
+virtualization deployments, a landscape for which the existing stack is
+not well suited.  These environments are often characterized by highly
+dynamic end-points, the maintenance of logical abstractions, and
+(sometimes) integration with or offloading to special purpose switching
+hardware.
+
+The following characteristics and design considerations help Open
+vSwitch cope with the above requirements.
+
+* The mobility of state: All network state associated with a network
+  entity (say a virtual machine) should be easily identifiable and
+  migratable between different hosts.  This may include traditional
+  "soft state" (such as an entry in an L2 learning table), L3 forwarding
+  state, policy routing state, ACLs, QoS policy, monitoring
+  configuration (e.g. NetFlow, sFlow), etc.
+
+  Open vSwitch has support for both configuring and migrating both slow
+  (configuration) and fast network state between instances.  For
+  example, if a VM migrates between end-hosts, it is possible to not
+  only migrate associated configuration (SPAN rules, ACLs, QoS) but any
+  live network state (including, for example, existing state which
+  may be difficult to reconstruct).  Further, Open vSwitch state is
+  typed and backed by a real data-model allowing for the development of
+  structured automation systems.
+
+* Responding to network dynamics: Virtual environments are often
+  characterized by high-rates of change.  VMs coming and going, VMs
+  moving backwards and forwards in time, changes to the logical network
+  environments, and so forth.
+
+  Open vSwitch supports a number of features that allow a network
+  control system to respond and adapt as the environment changes.  This
+  includes simple accounting and visibility support such as NetFlow and
+  sFlow.  But perhaps more useful, Open vSwitch supports a network state
+  database (OVSDB) that supports remote triggers.  Therefore, a piece of
+  orchestration software can "watch" various aspects of the network and
+  respond if/when they change.  This is used heavily today, for example,
+  to respond to and track VM migrations.
+
+  Open vSwitch also supports OpenFlow as a method of exporting remote
+  access to control traffic.  There are a number of uses for this
+  including global network discovery through inspection of discovery
+  or link-state traffic (e.g. LLDP, CDP, OSPF, etc.).
+
+* Maintenance of logical tags: Distributed virtual switches (such as
+  VMware vDS and Cisco's Nexus 1000V) often maintain logical context
+  within the network through appending or manipulating tags in network
+  packets.  This can be used to uniquely identify a VM (in a manner
+  resistant to hardware spoofing), or to hold some other context that
+  is only relevant in the logical domain.  Much of the problem of
+  building a distributed virtual switch is to efficiently and correctly
+  manage these tags.
+
+  Open vSwitch includes multiple methods for specifying and maintaining
+  tagging rules, all of which are accessible to a remote process for
+  orchestration.  Further, in many cases these tagging rules are stored
+  in an optimized form so they don't have to be coupled with a
+  heavyweight network device.  This allows, for example, thousands of
+  tagging or address remapping rules to be configured, changed, and
+  migrated.
+
+  In a similar vein, Open vSwitch supports a GRE implementation that can
+  handle thousands of simultaneous GRE tunnels and supports remote
+  configuration for tunnel creation, configuration, and tear-down.
+  This, for example, can be used to connect private VM networks in
+  different data centers.
+
+* Hardware integration: Open vSwitch's forwarding path (the in-kernel
+  datapath) is designed to be amenable to "offloading" packet processing
+  to hardware chipsets, whether housed in a classic hardware switch
+  chassis or in an end-host NIC.  This allows for the Open vSwitch
+  control path to be able to both control a pure software
+  implementation or a hardware switch.
+
+  There are many ongoing efforts to port Open vSwitch to hardware
+  chipsets.  These include multiple merchant silicon chipsets (Broadcom
+  and Marvell), as well as a number of vendor-specific platforms.
+
+  The advantage of hardware integration is not only performance within
+  virtualized environments.  If physical switches also expose the Open
+  vSwitch control abstractions, both bare-metal and virtualized hosting
+  environments can be managed using the same mechanism for automated
+  network control.
+
+In many ways, Open vSwitch targets a different point in the design space
+than the existing Linux networking stack, focusing on the need for
+automated and dynamic network control in large-scale Linux-based
+virtualization environments.
+
+The goal with Open vSwitch is to keep the in-kernel code as small as
+possible (as is necessary for performance) and to re-use existing
+subsystems when applicable (for example Open vSwitch uses the existing
+QoS stack).  Open vSwitch limits disruption by using existing hooks into
+the kernel, so Open vSwitch can be deployed as a module without
+requiring any modification to the kernel.