OpenContrail 3.0 brings to the table an impressive series of new features and enhancements. Some of them are especially useful for Service Chaining – and not only for Virtual Network Functions (VNF), but also for Physical Network Functions (PNF). This article describes a subset of these new features.
Decoupling Network from Compute in Service Chaining
In previous OpenContrail versions, Contrail acts like a Nova client and triggers the spawning of VNFs in OpenStack. We call this model v1 service chaining. Now, OpenContrail 3.0 supports both v1 and v2 (new!) service chaining. In the new model Contrail only takes care of the networking piece, which makes it easier to chain network functions implemented on a variety of compute flavors (VMs, containers, physical appliances).
The way we implement v2 service chaining is through Port Tuples. Let’s introduce one key concept (the VMI) and then discuss what Port Tuples are and their motivation.
One of the reasons why OpenContrail is so flexible in adopting new compute flavors (different typical hypervisors, containers, bare metal servers, etc.) is the VM Interface (VMI) concept. OpenContrail uses the VMI object abstraction as a means to interconnect a heterogeneous compute environment to the overlay network. Thanks to this abstraction layer, many of the features that were originally made to work for VMs also work seamlessly for other compute flavors.
In OpenContrail 3.0 we go one step further and define a Port Tuple as an ordered set of VM Interfaces. A given Port Tuple is an ordered list of network interfaces connected to the same VM, or container, or physical appliance. By chaining port tuples, it possible to build a service chain out of heterogeneous network functions, some of them virtual (VMs, containers) and others physical. In summary, Port Tuples are to NFV what VM Interfaces are to overlay networking.
Disclaimer: One of the scenarios displayed in the video (bare metal servers connected to vrouter CPE) is not supported at the time of this writing. It is shown as a way to illustrate the power of the port tuple concept and a possibly upcoming feature.
Service Chain Redundancy in Contrail
OpenContrail has recently boosted its control plane feature set in several ways. One of them is routing policies. If you are familiar with network operating systems like Junos or IOS XR, you have certainly experienced routing policies more than once. Well, in OpenContrail this feature works exactly in the same way. Thanks to routing policies, it is possible to filter and modify routes in a fine-grained manner, adding a much greater control plane flexibility within OpenContrail itself.
At the time of publication of this post, the infrastructure has been completely developed and routing policies can be applied to Service Instance interfaces (left, right). In other words, it is currently possible to do fine-grained route leaking through a Service Chain. And the same infrastructure can be used in the future for other purposes too.
Among other use cases, the currently available routing policy feature set allows for Service Chain Redundancy. You can have a primary service chain in data center #1 and the backup service chain in data center #2. Combined with the Service Health Check feature, Service Providers can easily implement HA on their NFV offerings.
