Jump to: navigation, search


Quantum L3 (Forwarding) Model and API

Update: Here is a revised model based on feedback:

|alt L3 Model Schematic


Today’s Quantum Service implements Virtual Network (L2) abstractions. Using Quantum's RESTful API, clients can create virtual networks, ports on the virtual networks, and attach VM VIFs to these ports. However, the Quantum service lacks knowledge of L3 constructs like Subnets, and the ability to configure routing between these Subnets. To overcome this limitation, and to in general, incorporate L3 semantics, this document proposes a Quantum L3 model of resources, and a specification for implementing the model.


Please refer to the attached file:

alt L3 Model Schematic


Quantum abstracts the physical implementation of the network, allowing plugins to configure and manage physical and virtual resources. Quantum is a standalone service, in that it requires no other project within OpenStack to function correctly. Current implementation of Quantum provides for L2 network abstraction. The proposal in this document extends Quantum service to provide L3 abstractions. These L3 abstractions will be exposed as a separate API, but part of the same Quantum service (base Quantum URI remains the same).

Further, the Quantum L3 abstractions are agnostic of the entities that realize them and use them. The L3 abstractions can be realized by a separate L3 plugin. Thus, it would be possible to deploy different combinations of L2 and L3 plugins within the same installation (even simultaneously enabling plugins from different vendors). The plugin in turn would configure one or more physical or virtual resources (or a combination of both). On the client side, we anticipate that Nova will be the predominant consumer; however other entities can consume the L3 services just as well.

A tenant creates one or more Subnets using the Quantum L3 API (defined in Section 7). VMs on any Subnet have access to other VMs on the same Subnet. To provide access to the VMs outside the Subnet, Routes need to be created indicating the desired connectivity.

Routes are part of a Route-table. Each Route entry consists of Source, Destination, and Target IDs. For instance, if a tenant wants to set up connectivity such that a Subnet A, needs to have access to the Internet, he would perform the following steps:

  1. Create Subnet A
  2. Create Route-table, RT-A
  3. Associate Subnet A with Route-table RT-A
  4. Create a Route in the Route-table:
    <Source: Subnet A, Destination:, Target: Public>

The Route entry in step 4 indicates that traffic from any VMs on Subnet A, which is not on that Subnet needs to go the Public network.

Note: Route entries and Route-tables referred here are logical abstractions, and may result in the creation of one more route entries and/or policies in the underlying L3 infrastructure.

The Service Provider in response to these API calls, will set up the necessary infrastructure to achieve the above connectivity. Exactly how this setup is achieved will be specific to the particular plugin which implements the L3 abstractions. In the above case, the plugin could instantiate a virtual or physical gateway entity to route the traffic to and from the Subnet A to the Public network. It should be noted that in this model the tenant does not directly manage the gateway device, it’s instantiated and managed by the Service Provider, the tenant merely references it by using the “Public” target.

(Contact: Sumit Naiksatam, Ram Durairaj)