- AT&T Foundry
Supporters & Interest
- Anuta Network
Quantum, as well as other Openstack services, has introduced the concept of a plugin, which is a pluggable back-end implementation of the Networking API. A plugin can use a variety of technologies to implement the logical API requests. Some Quantum plugins might use basic Linux VLANs and iptables tools, while others might use more advanced technologies, such as L2-in-L3 tunneling or OpenFlow, to provide similar benefits.
The scope of these technology-specific plugins is not defined nor limited in Quantum. Therefore, plugins could cover any networking layers within the data center from the Core layer (including Aggregation and Access layers) to the server virtualization layer, commonly known as the virtual switch.
Quantum currently supports the instantiation of only one plugin per deployment. This is a limitation that some developers have overcome by implementing plugins that re-deploy existing plugins and in other cases deploying multiple plugins at the same time. For instance, Cisco plugin re-deploys OVS plugin and its own NXOS plugin. Other approaches such as metaplugin deploys more than one plugin at the same time letting the Quantum API user to decide which plugin to use based on an API extension.
A network topology may have multiple networking elements (physical and virtual), and these elements could be a combination of different types/technologies. This is usually a hard problem to solve in a generic way. We propose a new Quantum plugin framework that can handle these generic requirements, and provide a reference implementation of this plugin framework such that it can be extended and customized.
The Quantum architecture needs modification in order to define the scope for each plugin based on the data center topology classification. Basically, there are two infrastructure domains in data centers, the Virtual Networking Infrastructure (VNI) and Physical Networking Infrastructure (PNI). Figure 1 shows this separation.
It is clear that the networking configuration between the PNI and VNI domains might share some common functionality but at the same time both domains have very unique features that could be exploited by the computing administrator if plugins per infrastructure domain are implemented instead of just one plugin covering the whole system.
In fact, most of the Quantum plugins cover one or the other infrastructure domain but not entirely both. There is an essential need to re-define Quantum architecture to consider a clear definition between PNI and VNI .
Description & Motivation
This document proposes a new pluggable architecture model for Quantum, where different types of plugins manage Physical Networking Infrastructure (PNI) and Virtual Networking Infrastructure (VNI). These plugins will be technology specific and their scope is limited to the capabilities of the domain where they belong. Quantum users will decide which PNI and/or VNI plugin to include in their deployment, Quantum should allow the use of one plugin per type but including multiple plugins could be discussed. Figure 2 shows the proposed architecture.
No major changes are required for the persistence and segmentation layers for this new pluggable architecture. However, each plugin could keep extending the base DB schema base on the extensions exposed.
PNI/VNI sub plugins under Quantum pluggable framework is more towards allowing interoperability of technologies that complement their functions between each other. The major benefit is that the coexistence and interoperability of PNI and VNI vendors offers a better solution to the customers. A part, the current model of a single mutually exclusive quantum plugin leads to miscorrelation between PNI and VNI configuration or on the other hand to complex and in some cases hard-coded network orchestration functions. The right network functionality is force to work in current design whereas in this proposal Quantum will provide the best of both domains in an independent architecture.
The API could also be separated by domain. As Quantum evolves, some APIs will make more sense at one domain or another. Therefore, it makes sense to separate the API implementation,
OpenStack Dashboard Integration
Dashboard should not suffer any changes but it could start exposing information about PNI that it did not expose before. It will enrich the information that the cloud administrator will obtain for the UI.
- Clear definition of the networking scope for each plugin
- Simplify the development of new technology-specific plugins
- Avoid redundant calls between plugins
- Integrate new PNI and VNI functions by means of plugin extensions
- Easier to implement new extensions
Use case will consist of 2 compute, 1 storage, and 1 operations node in a mulit-host configuration with Cisco Nexus (NXOS) ToR switches providing PNI services and Linux Bridge (LB) VNI provider.
The Quantum plugin will provide an abstraction of the underlying data models. Access and modification by the PNI/VNI implementations will be done via an API. Any plugin specific data persistence will be provided through the Quantum extension mechanism.
We kindly request feedback for the community to complete this proposal, share with us your comments, reviews and ideas.