openstack
/
dragonflow
Code Issues Proposed changes

README: Cleanup and refactor 

This mostly wraps lines at 80 characters, and cleans a few things
up while here.

Change-Id: I11b48e77bb6217cc6c4ca2cc9a639c5cc27ac9c7
Signed-off-by: Kyle Mestery <mestery@mestery.com>
This commit is contained in:
Kyle Mestery 2015-07-28 15:49:16 +00:00
parent fff4c83c45
commit 33f33baf75
1 changed files with 38 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
README.rst
View File

@ -21,15 +21,23 @@ Documentation:
Overview
--------
Dragonflow is an implementation of a fully distributed virtual router for OpenStack Neutron, which is based on a Software-Defined Network Controller (SDNC) design.
Dragonflow is an implementation of a fully distributed virtual router for
OpenStack Neutron, which is based on a Software-Defined Network Controller
(SDNC) design.
The main purpose of Dragonflow is to simplify the management of the virtual router, while improving performance, scale and eliminating single point of failure and the notorious network node bottleneck.
The main purpose of Dragonflow is to simplify the management of the virtual
router, while improving performance, scale and eliminating single point of
failure and the notorious network node bottleneck.
The proposed method is based on the separation of the routing control plane from the data plane.
This is accomplished by implementing the routing logic in distributed forwarding rules on the virtual switches.
In OpenFlow these rules are called flows. To put this simply, the virtual router is implemented using OpenFlow flows.
The proposed method is based on the separation of the routing control plane
from the data plane. This is accomplished by implementing the routing logic in
distributed forwarding rules on the virtual switches. In OpenFlow these rules
are called flows. To put this simply, the virtual router is implemented using
OpenFlow flows.
Dragonflow eliminates the use of namespaces in contrast to the standard DVR. A diagram showing Dragonflow components and overall architecture can be seen here:
Dragonflow eliminates the use of namespaces in contrast to the standard DVR
implementation. A diagram showing Dragonflow components and overall
architecture can be seen here:
.. image:: https://raw.githubusercontent.com/openstack/dragonflow/master/doc/images/df_components.jpg
:alt: Solution Overview
@ -38,9 +46,10 @@ Dragonflow eliminates the use of namespaces in contrast to the standard DVR. A d
:align: center
Perhaps the most important part of the solution is the OpenFlow pipeline which we install into the integration bridge upon bootstrap.
This is the flow that controls all traffic in the OVS integration bridge `(br-int)`.
The pipeline works in the following manner:
Perhaps the most important part of the solution is the OpenFlow pipeline which
we install into the integration bridge upon bootstrap. This is the flow that
controls all traffic in the OVS integration bridge `(br-int)`. The pipeline
works in the following manner:
::
@ -49,11 +58,14 @@ The pipeline works in the following manner:
1. If it is ARP, forward to the ARP Responder table
2. If routing is required (L3), forward to the L3 Forwarding table
(which implements a virtual router)
3. All L2 traffic and local subnet traffic are offloaded to the NORMAL pipeline handled by ML2
3. All L2 traffic and local subnet traffic are offloaded to the NORMAL
pipeline handled by ML2
4. North/South traffic is forwarded to the network node (SNAT)
The following diagram shows the multi-table OpenFlow pipeline installed into the OVS integration bridge `(br-int)` in order to represent the virtual router using flows only:
The following diagram shows the multi-table OpenFlow pipeline installed into
the OVS integration bridge `(br-int)` in order to represent the virtual router
using flows only:
.. image:: https://raw.githubusercontent.com/openstack/dragonflow/master/doc/images/df_of_pipeline.jpg
@ -86,14 +98,21 @@ Features
--------
* APIs for routing IPv4 East-West traffic
* Performance improvement for inter-subnet network by removing the amount of kernel layers (namespaces and their TCP stack overhead)
* Scalability improvement for inter-subnet network by offloading L3 East-West routing from the Network Node to all Compute Nodes
* Reliability improvement for inter-subnet network by removal of Network Node from the East-West traffic
* Performance improvement for inter-subnet network by removing the amount of
kernel layers (namespaces and their TCP stack overhead)
* Scalability improvement for inter-subnet network by offloading L3 East-West
routing from the Network Node to all Compute Nodes
* Reliability improvement for inter-subnet network by removal of Network Node
from the East-West traffic
* Simplified virtual routing management
* Support for all type drivers GRE/VXLAN/VLAN
* Support for centralized shared public network (SNAT) based on the legacy L3 implementation
* Support for centralized floating IP (DNAT) based on the legacy L3 implementation
* Support for HA, in case the connection to the Controller is lost, fall back to the legacy L3 implementation until recovery. Reused all the legacy L3 HA. (Controller HA will be supported in the next release).
* Support for centralized shared public network (SNAT) based on the legacy L3
implementation
* Support for centralized floating IP (DNAT) based on the legacy L3
implementation
* Support for HA, in case the connection to the Controller is lost, fall back
to the legacy L3 implementation until recovery. Reused all the legacy L3 HA.
(Controller HA will be supported in the next release).
* Supports for centralized IPv6 based on the legacy L3 implementation
TODO
@ -102,5 +121,6 @@ TODO
* Add support for North-South L3 IPv4 distribution (SNAT and DNAT)
* Add support for IPv6
* Support for multi controllers solution
Full description can be found in the project `Blueprints <https://blueprints.launchpad.net/dragonflow>`_
Full description can be found in the project `Blueprints
<https://blueprints.launchpad.net/dragonflow>`_