One of the key concepts in OpenStack, or for that matter, any cloud infrastructure platform, is multi-tenancy. The definition of tenants varies based on the usage of cloud. Tenants could be organizations that allow one or more employees to make use of cloud platforms. While such an organization is considered a tenant, the employees are called users. For privacy and security reasons, it is important to isolate the data traffic of one tenant from another. Therefore, traffic isolation is a key element of cloud and software-defined networking.

The physical networking devices are basically connected using wires. These devices provide specific functionality such as switching, routing and security, and so on. The networking devices connect physical servers. Therefore, applications hosted on these servers directly leverage the underlying fixed network connectivity. With the advent of cloud computing, there is a firm trend of applications and servers getting virtualized. As a consequence, networks are also getting virtualized, and software defined.

In a cloud environment, the physical infrastructure, namely, the servers, storage, and networking, is shared by multiple tenants. As mentioned previously, physical networking infrastructure is wired in a specific manner. But different applications belonging to different tenants may require completely different networking capabilities. Service chaining is the mechanism by which software-based networking functions (VNF) are stitched to provide powerful networking constructs for applications. Moreover, these software networking capabilities are expected to leverage the underlying fixed physical networks. This ensures that different tenants can leverage the same shared hardware but are able to define and build their own software-defined networks.

Let us understand this with the help of an example. In traditional networks, traffic originates from a server and passes through one or more switches into a router or firewall device. On the physical firewall device, the network traffic is subjected to multiple security functions, such as firewall, VPN, IDP, anti-virus, and so on. Therefore, the flow of traffic is highly static due to the fixed nature of network traffic. As the network traffic scales, the need to deploy more firewall appliance increases, adding to the total cost of operating the network. The security functions are mostly software applications and can run very well on standard server-class machines.

As modern data centers evolved and cloud became popular, there was an increased need to use the server compute capacity to run these specialized network functions. For example, if there is a need to apply more anti-virus checks, it is possible to auto scale only the anti-virus software function on-demand. This network architecture is needed for large-scale data centers and cloud. These software-based networking functions are also called Virtual Network Function (VNF).

But this is just a part of the solution. As more VNFs are deployed, it is important to ensure that traffic from one VM instance is appropriately sent to its corresponding VNF for processing. And the processed traffic may have to be sent to yet another VNF handling a different function. This ability to direct network traffic through a series of VNF is called service chaining.

VTN is an OpenDaylight feature that supports multi-tenancy as well as the chaining of network services. It introduces several networking constructs inside ODL that place power and flexibility at the hand of the end user. This allows end users to define any complex networking required for their applications using software. And as a controller, ODL implements software-defined networks on fixed physical networking hardware.

VTN comprises two components:

From an OpenStack perspective, we need to focus only on VTN Manager, since it supports integration with Neutron. In the following sections, we will show the mapping of OpenStack Networking entities to the corresponding VTN objects.

As mentioned previously, VTN uses a specific object model to implement a multi-tenant virtual network. The model provides a logical abstraction, which allows users to define different types of virtual networks depending on their need. The VTN model can then be mapped to the underlying physical infrastructure and provide real networking connectivity.

The VTN model can be broadly classified into three types of entities. These are as follows:

These are the most important entities that make up the VTN model. As mentioned previously, users can create a complete network model using these entities in OpenDaylight. Once a virtual network model is defined, the next step is to provide mapping.

Mapping is provided by associating the vInterfaces to interfaces on the physical networks. Since multi-tenancy is a requirement, it is common to map more than one vInterface to the same physical network port. However, in this case, the mapping must also define how the isolation of traffic needs to happen on the physical port.

Let us understand modeling and the mapping process with the help of a simple example.

The setup shown in the following diagram has two servers, each containing two virtual machines. The servers are connected to the physical switch at ports PIF1 and PIF2:

Mapping of physical layer resources to VTN model

In terms of virtual network, the virtual machines belong to two different tenants. This is represented using VTN Blue and VTN Green respectively. The corresponding VTN model consists of two vBridge entities, each with two vInterfaces, VIF1 and VIF2.

Once the model is defined, it is important to map the virtual interfaces to the physical interfaces. Since the physical interface on the switch is common to both virtual networks, we will have to use isolation mechanisms, such as VLAN. So a simple VLAN-based mapping could be as follows:

So far, we have seen a high-level overview of VTN concepts in OpenDaylight. Let us now get a more hands-on understanding of VTN and how the models and mappings are realized in an OpenStack environment.

The first step is to install VTN manager features in ODL. At the ODL Karaf prompt, execute the commands shown here to install VTN manager:

The preceding steps integrate Neutron support for VTN. Once the odl-vtn-manager-neutron module is installed, ODL is able to convert OpenStack Networking entities such as network, port, and so on, into corresponding VTN objects.