From 3c34dd48afdb134f74099c5b84fe5bdc33656023 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Thu, 17 Jun 2010 10:24:39 -0700 Subject: [PATCH] WHY-OVS: New file explaining the rationale for Open vSwitch. Signed-off-by: Martin Casado Signed-off-by: Paul Fazzone Signed-off-by: Dan Wendlandt --- Makefile.am | 1 + WHY-OVS | 104 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 105 insertions(+) create mode 100644 WHY-OVS diff --git a/Makefile.am b/Makefile.am index fd6c56cc..62d4d491 100644 --- a/Makefile.am +++ b/Makefile.am @@ -43,6 +43,7 @@ EXTRA_DIST = \ README-gcov \ REPORTING-BUGS \ SubmittingPatches \ + WHY-OVS \ boot.sh bin_PROGRAMS = sbin_PROGRAMS = diff --git a/WHY-OVS b/WHY-OVS new file mode 100644 index 00000000..ac9a3815 --- /dev/null +++ b/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. -- 2.30.2