Press Inquiries
Please contact us for any press inquiries
Contact Us
X
Elina Edefalk
By Elina Edefalk
February 7, 2018

The stars have aligned. It’s 2018 and automation is the word on everyone’s lips.

Maturity improvements in SDN and NFV deployments are here; they were key. They’re still not perfect, but they can do the job.

Let’s break that down a bit more: what do we mean by NFV, SDN, and automation?

There’s no way to take advantage of automation with deployments of every physical network function (PNF). To ship, rack, stack, cable, test, dimension, configure, and setup monitoring in a manual process just doesn’t work. Having a telco or public cloud NFVI deployed in the “right” places in the network for your VNFs is a clear requirement for automation. Since the main purpose of automation is to cut costs, the NFVI also needs to be low-cost and cheap to operate. That same requirement applies for the MANO side - it needs to work and, it needs to be cheap to operate.

Considering NFV’s now massive five-year history this should be fine, right? Well…

If you follow Sandvine, you’ll get a sense of the maturity in the space. We will help you navigate progress and status in both the popular NFVI and MANO stacks and understand if the pieces you need for automation are there. Right now the answer, simply put, is ‘not quite’; not for data plane nor any vendor. ONAP and OSM are probably the closest on the MANO side, but remember where we’re coming from here: Telco grade, high performance, full automation, full interoperability, no handholding, manual patching, manual steps, etc. We don’t play around; our requirements are tough.

No matter what, there needs to be a functioning descriptor where you can describe your VNF and its virtual requirements. A functioning NS (Network Service) layer is fundamental and needs a descriptor of its own. If that’s not enough, there needs to be a mechanism for scaling in and out – one that works at the NS layer too – with all the complexities of data plane state and load balancing.

The data plane – Oh, it’s so special
For data plane applications, such as Sandvine’s PacketLogic, the most important aspect of NFV is the virtual networks. The rest of NFV is easy for us. Give us virtual compute and virtual storage, and we’re good (you may be disappointed with poor IOPS on storage!). Computing is easy. Computing with a few packets here and there is also easy. But drinking from a fire hose of hundreds of gigabits of traffic, fully saturating cables, switches, virtual switching, and virtual networks, is completely different.

But let’s assume that the performance is ok and that our VNFc can attach to the virtual network resources in the NFVI. The challenge comes when you need to automatically scale out a data plane application. If you’re a networking guy thinking about a data plane VNF as either a layer 2 or a layer 3 hop, maybe you can see how this gets funky – Unless your VNFc is guaranteed to always be able to handle the full fire hose, the traffic needs to be split up and directed to the set of VNFc that makes up your VNF. And that is exclusively, in our view, the job of the virtual network infrastructure, i.e., the SDN and the virtual switch in the NFVI.

Load balancing could be as easy as a slice in the network, a VXLAN, an MPLS label, VLAN, etc. However, that assumes some kind of static thinking, and while not strictly manual, managing such a network resource mapping is tricky.

At Sandvine, we don’t impose requirements on how the virtual networks are balanced. We avoid round-robin balancing of packets from the same flow as that will introduce re-ordering, but otherwise, we’re happy. A single subscriber’s traffic can pass any number of our function instances. The downstream traffic for a flow can traverse/pass through one instance and the upstream traffic for the same flow can pass through another (also referred to as asymmetric traffic). Because of how we implement our state sharing in PacketLogic (aka FlowSync, NATsync, QSync protocols), the networking engineer does not have to account for flow or subscriber affinity when tracing the packet flow. As a result, when we come across common classic networking techniques like ECMP routing or channel bonding, we feel much more at home. If it worked in a physical world for balancing traffic across links, it will work in a virtual world. That’s good enough for us.

For a scale-out operation, consider the moment the SDN decides to change the traffic balancing. The move can of course be stateful, meaning the flows that are already handled by the first instance stay on the first instance and new flows are sent to the newly scaled out instance. That’s a huge requirement of the SDN switch though. Just like in the physical world with layer 2 and layer 3 switches and routers, you want them to be as dumb as possible. Keeping state means complexity and loss of performance. Ultimately, that’s not what you want at those layers in the network. But today, that’s how most SDN switches operate; with a full flow table and stateful operations on each flow.

Enter Juniper Contrail
Now that we’ve broken down the key ingredients for successful automation we’ll provide an example of a successful implementation, featuring Sandvine’s PacketLogic and Juniper Networks SDN controller Contrail.

juniper

Note: HEAT is not an NFVO in the ETSI NFV definition, but solves some of the same functions.

Contrail is a well-established and popular SDN platform for cloud networks. We understand why, since its approach is straightforward. What you see is what you get. Once installed, it utilizes the same logic as most well-known networking technologies, and will be familiar to most network engineers. Contrail fully supports SFC (Service Function Chaining) by using SDN capabilities to create a service chain, which if you’re using a PacketLogic data plane instance (the vPRE), would include at least one PRE VNF.

With Contrail, we’re able to provide our customers with a solution that can scale a service chain automatically, in or out, based on load metrics. This elasticity can provide operators with an automated solution that responds to unexpected shifts in demand, quickly and cheaply. 

PRE.png

The diagram above shows a single-instance PRE in a service chain controlled by the Contrail vRouter. The PRE is supported by a few PacketLogic control plane elements; the PacketLogic Subscriber Manager (PSM) and the PacketLogic Intelligence Center (PIC). In this example, a packet generator (TRex) is used to generate the traffic west and eastbound through the PRE.

As the traffic increases, the scale-out function of Contrail will react to the higher load reported by the PRE and automatically scale out another instance of the PRE, while automatically splitting the traffic between the two PREs using an ECMP mechanism in the vRouter. As a health-checking mechanism (and to make sure that the newly spawned PRE is ready to accept traffic), vRouter supports a few different mechanisms. However, for us a simple ping function is sufficient.

Contrail uses the HEAT engine in OpenStack and the scaling operation follows the same logic in Contrail as in HEAT. Even the Contrail-specific scale-out mechanism is inherited from the standard AutoScalingGroup in HEAT. 

Likes

  • The Contrail UI is powerful and provides far more introspection than regular OpenStack Horizon
  • The use of HEAT and Contrail extensions is very clean and gets the job done
  • Contrail provides load balancing and service function chaining that works

Dislikes

  • The Contrail templates mix JSON and YAML, which is a bit confusing
  • Some of the Contrail data structures are recursive
  • Hard to fit the Contrail architecture into the ETSI NFV framework 

In Summary
HEAT is not an ETSI NFV-supported descriptor language, and the NFVO and VNF-M components with their standardized interfaces simply do not align with how Contrail is architected. However, that matters less than what the solution does and Contrail gets the job done. For cloud deployments of data plane VNFs, the Contrail vRouter has critical features (so far unmatched) and HEAT. Furthermore, the Contrail extensions are viable as a mechanism for orchestration, including defining a network service with multiple VNFs. If you are interested in downloading our PacketLogic VNF packages for Contrail, see this link: https://github.com/sandvine/sandvine-nfv-descriptors/tree/18.1.2.0/Sandvine_PacketLogic.


Topics: Featured Blog Header, Featured, VNF, Automation