Jump to: navigation, search

Difference between revisions of "Neutron/OFAgent/ComparisonWithOVS"

 
(14 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
* What's same?
 
* What's same?
−
** Basic architecture; the agent controls an OpenFlow switich on the node.
+
** Basic architecture
 +
*** the agent runs on each compute/network node.
 +
*** it controls an OpenFlow switich on the node.
  
 
* What's different?
 
* What's different?
Line 38: Line 40:
 
|-
 
|-
 
| Port monitoring
 
| Port monitoring
−
| Periodic poll of ovsdb via [http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-vsctl.8 ovs-vsctl] command
+
| ovsdb monitoring via [http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-vsctl.8 ovs-vsctl] command
−
| OpenFlow port statistics and notification ([https://blueprints.launchpad.net/neutron/+spec/ofagent-port-monitor planned])
+
| OpenFlow port statistics.  Accept async messages to monitor changes ([https://review.openstack.org/#/c/138618/ planned])
 
|-
 
|-
 
| Management Protocol (eg. tunnel port creation)
 
| Management Protocol (eg. tunnel port creation)
Line 47: Line 49:
 
| Device ID
 
| Device ID
 
| Neutron port ID (UUID) stored in ovsdb
 
| Neutron port ID (UUID) stored in ovsdb
−
| Port name as linuxbridge ([https://blueprints.launchpad.net/neutron/+spec/ofagent-port-monitor planned])
+
| Port name as linuxbridge
 
|-
 
|-
 
| "internal" VLAN
 
| "internal" VLAN
 
| 802.1q tagged VLAN
 
| 802.1q tagged VLAN
−
| OpenFlow metadata ([https://blueprints.launchpad.net/neutron/+spec/ofagent-merge-bridges planned])
+
| OpenFlow metadata
 
|-
 
|-
 
| Local ARP responder
 
| Local ARP responder
−
| Install NX flows for each FDB entries ([https://bugs.launchpad.net/neutron/+bug/1237427 merged])
+
| Install NX flows for each FDB entries. Currently tunnel network types only.
−
| The embedded OpenFlow controller handles packet-ins and sends back ARP responses ([https://blueprints.launchpad.net/neutron/+spec/ofagent-l2pop planned])
+
| The embedded OpenFlow controller handles packet-ins and sends back ARP responses. Implemented for all network types.
 
|-
 
|-
 
| Multiple bridges
 
| Multiple bridges
 
| Considering [http://summit.openstack.org/cfp/details/391 bridges per functionalities].
 
| Considering [http://summit.openstack.org/cfp/details/391 bridges per functionalities].
−
| Aims to reduce the number of bridges because multiple bridges and patch ports are not supported by every switch implementations. ([https://blueprints.launchpad.net/neutron/+spec/ofagent-merge-bridges planned])
+
| Uses a single bridge in favor of portability.
 
|-
 
|-
−
| Security Groups
+
| Security Groups / Firewall driver
−
| use NX like tcp_flags NXM, learn action, or conntrack ([https://review.openstack.org/#/c/89712/ planned])
+
| use NX.  namely tcp_flags NXM, learn action, or future conntrack support ([https://review.openstack.org/#/c/89712/ planned])
−
| probably implement only a subset of rules using OpenFlow
+
| probably implement only a subset of rules using plain OpenFlow
 +
|-
 +
| Tagged VLANs in tenent network
 +
| Not supported
 +
| Supported
 +
|-
 +
| XenAPI (Agent in a separate domain)
 +
| Supported using a special rootwrap
 +
| Not supported
 +
|-
 +
| L2population
 +
| Optional
 +
| Mandatory
 +
|-
 +
| DVR
 +
| Supported
 +
| Not supported
 
|-
 
|-
 
|}
 
|}

Latest revision as of 03:34, 5 December 2014

Two neutron agents, openvswitch and ofagent, implement mostly same functionalities in different ways.

  • What's same?
    • Basic architecture
      • the agent runs on each compute/network node.
      • it controls an OpenFlow switich on the node.
  • What's different?
    • The following is a summary of the differences.
    • note: this list is intended to show differences wrt designs and development directions. some of items (noted as "planned") have not been implemented in neutron master yet.
openvswitch ofagent
Advantages Possibly can achieve better performance using Open vSwitch(OVS) specific advanced features like Nicira Extensions (NX) and patch ports. More portable to switches other than OVS. Easier to handle asynchronous messages because it's a full featured OpenFlow controller.
OpenFlow version OpenFlow 1.0 + NX OpenFlow 1.3 without vendor extensions
How to compose flows? ovs-ofctl command line arguments (plain texts) Use Ryu ofproto library (python objects)
How to install flows into a switch? Invoke ovs-ofctl command An OpenFlow controller embedded in the agent sends OpenFlow messages to the switch
Supported switches OVS only OpenFlow 1.3 switches including OVS (planned)
Neutron plugin openvswitch plugin (planned to be deprecated) or ML2 plugin ML2 plugin
Port monitoring ovsdb monitoring via ovs-vsctl command OpenFlow port statistics. Accept async messages to monitor changes (planned)
Management Protocol (eg. tunnel port creation) ovsdb via ovs-vsctl command use standard protocols like OF-Config where appropriate. otherwise, sub-driver (planned)
Device ID Neutron port ID (UUID) stored in ovsdb Port name as linuxbridge
"internal" VLAN 802.1q tagged VLAN OpenFlow metadata
Local ARP responder Install NX flows for each FDB entries. Currently tunnel network types only. The embedded OpenFlow controller handles packet-ins and sends back ARP responses. Implemented for all network types.
Multiple bridges Considering bridges per functionalities. Uses a single bridge in favor of portability.
Security Groups / Firewall driver use NX. namely tcp_flags NXM, learn action, or future conntrack support (planned) probably implement only a subset of rules using plain OpenFlow
Tagged VLANs in tenent network Not supported Supported
XenAPI (Agent in a separate domain) Supported using a special rootwrap Not supported
L2population Optional Mandatory
DVR Supported Not supported
Retrieved from "https://wiki.openstack.org/w/index.php?title=Neutron/OFAgent/ComparisonWithOVS&oldid=69704"