Difference between revisions of "Neutron/OFAgent/ComparisonWithOVS"
(44 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Two neutron agents, openvswitch and ofagent, implement mostly same functionalities in different ways. | Two neutron agents, openvswitch and ofagent, implement mostly same functionalities in different ways. | ||
− | The following is a summary of the differences. | + | |
+ | * 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. | ||
{| border="1" cellpadding="2" cellspacing="0" | {| border="1" cellpadding="2" cellspacing="0" | ||
Line 8: | Line 16: | ||
|- | |- | ||
| Advantages | | 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. | | More portable to switches other than OVS. Easier to handle asynchronous messages because it's a full featured OpenFlow controller. | ||
|- | |- | ||
| OpenFlow version | | OpenFlow version | ||
− | | OpenFlow 1.0 + | + | | OpenFlow 1.0 + NX |
− | | | + | | OpenFlow 1.3 without vendor extensions |
+ | |- | ||
+ | | How to compose flows? | ||
+ | | [http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-ofctl.8 ovs-ofctl] command line arguments (plain texts) | ||
+ | | Use [http://ryu.readthedocs.org/en/latest/ofproto_ref.html Ryu ofproto library] (python objects) | ||
|- | |- | ||
− | | How to | + | | How to install flows into a switch? |
− | | Invoke ovs-ofctl command | + | | Invoke [http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-ofctl.8 ovs-ofctl] command |
− | | An OpenFlow controller embedded in the agent sends messages to the switch | + | | An OpenFlow controller embedded in the agent sends OpenFlow messages to the switch |
|- | |- | ||
| Supported switches | | Supported switches | ||
− | | OVS only | + | | OVS only |
| OpenFlow 1.3 switches including OVS ([https://wiki.openstack.org/wiki/Neutron/OFAgent/Todo planned]) | | OpenFlow 1.3 switches including OVS ([https://wiki.openstack.org/wiki/Neutron/OFAgent/Todo planned]) | ||
|- | |- | ||
Line 28: | Line 40: | ||
|- | |- | ||
| Port monitoring | | Port monitoring | ||
− | | | + | | ovsdb monitoring via [http://openvswitch.org/cgi-bin/ovsman.cgi?page=utilities%2Fovs-vsctl.8 ovs-vsctl] command |
− | | OpenFlow port statistics | + | | OpenFlow port statistics. Accept async messages to monitor changes ([https://review.openstack.org/#/c/138618/ planned]) |
+ | |- | ||
+ | | Management Protocol (eg. tunnel port creation) | ||
+ | | ovsdb via ovs-vsctl command | ||
+ | | use standard protocols like [https://www.opennetworking.org/sdn-resources/onf-specifications/openflow-config OF-Config] where appropriate. otherwise, sub-driver ([https://blueprints.launchpad.net/neutron/+spec/ofagent-sub-driver planned]) | ||
+ | |- | ||
+ | | Device ID | ||
+ | | Neutron port ID (UUID) stored in ovsdb | ||
+ | | Port name as linuxbridge | ||
|- | |- | ||
| "internal" VLAN | | "internal" VLAN | ||
| 802.1q tagged VLAN | | 802.1q tagged VLAN | ||
− | | OpenFlow metadata | + | | OpenFlow metadata |
|- | |- | ||
| Local ARP responder | | Local ARP responder | ||
− | | Install NX flows for each | + | | 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:// | + | | The embedded OpenFlow controller handles packet-ins and sends back ARP responses. Implemented for all network types. |
+ | |- | ||
+ | | Multiple bridges | ||
+ | | Considering [http://summit.openstack.org/cfp/details/391 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 ([https://review.openstack.org/#/c/89712/ 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 | ||
+ | |- | ||
|} | |} |
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.
- Basic architecture
- 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 |