Difference between revisions of "Quantum-sdn-controler-improvement"
(→Overview) |
(→Overview) |
||
| Line 11: | Line 11: | ||
| − | Nevertheless, it is also possible to use OpenStack Networking as the “[http://en.wikipedia.org/wiki/Routing_control_plane control plane]” (with LinuxBridge, OpenVSwitch, Cisco, Brocade). But has OpenStack Networking been developed with this role in mind, or is it mostly an interface between the networking API and the [http://en.wikipedia.org/wiki/Software-defined_networking SDN] "[http://en.wikipedia.org/wiki/Routing_control_plane control plane]? | + | Nevertheless, it is also possible to use OpenStack Networking as the “[http://en.wikipedia.org/wiki/Routing_control_plane control plane]” (with LinuxBridge, OpenVSwitch, Cisco, Brocade). But has OpenStack Networking been developed with this role in mind, or is it mostly an interface between the networking API and the [http://en.wikipedia.org/wiki/Software-defined_networking SDN] "[http://en.wikipedia.org/wiki/Routing_control_plane control plane]"? |
'''Facts:''' | '''Facts:''' | ||
Revision as of 08:42, 9 April 2013
Overview
Numerous limitations have been identified which prevent using free/libre plugins such as OpenVSwitch or LinuxBridge for large scale deployments.
At this time, the OpenStack networking project is designed to be interfaced with a third party controller which handles the “control plane” (NVP, Midonet, Ryu, Big Switch, Brocade, NEC, PLUMgrid).
The third party controllers have the following primary objectives (outside of the user directed functionality):
- scalability
- high availability
- exploitatability (monitoring, debugging, billing, capacity planning, etc...)
- efficiency of virtualization technologies (scalability, performances...)
Nevertheless, it is also possible to use OpenStack Networking as the “control plane” (with LinuxBridge, OpenVSwitch, Cisco, Brocade). But has OpenStack Networking been developed with this role in mind, or is it mostly an interface between the networking API and the SDN "control plane"?
Facts:
- the controller role is only endorsed by the OpenStack networking API through the code of the selected plugin.
- the communication protocol between the control plane and the data place is based on AMQP (RabbitMQ, ZeroMQ, Qpid - Oslo RPC)
- a database is used to save the state of the NaaS at any specific time
- high availability: the OpenStack networking daemon can be instantiated as many time as necessary
Improvements:
- split the ‘quantum-api’ daemon in separated roles to improve scalability and security: API, scheduling and plugin.
- add exploitability functions:
- monitoring (like this bp)
- debugging
- etc
- Improve the overlay technology of the open source plugin like LinuxBridge or OVS (disabling full-mesh of OVS...)
- merge the two open source plugins LinuxBridge and OVS. We can imagine the LinuxBridge working with overlay technologies (like VXLAN implemented in Linux kernel 3.8) instead of the classic VLAN isolation. Only one open source plugin with two or more possible drivers like LinuxBridge or OVS
This blueprint intended to open the discussion within the community to define more precisely the area of improvements and priorities.
Remarks:
