Author’s Note: There’s a lot of talk and plenty of noise related to NFV in the telecom industry. It’s a time of market transformation with many executives and marketers making claims for how their companies are doing NFV better than others, or how they are ahead of the competition in one or more ways. I think we are missing an important voice: The CTOs. I am talking with my peers from service providers and suppliers to get a sense of what is real. I am sharing these conversations in this series called The Real CTOs of NFV. The title is fun but the intent is serious. Following is my Real CTO conversation with Jerome Tollet of Qosmos.

Prayson: Jerome, thank you for joining me today. Qosmos has been heavily involved in NFV from almost the very beginning as one of the members of CloudNFV. Tell me a little about Qosmos’ role in the NFV transformation.

Jerome: Indeed, we have been in the NFV space since the beginning. We specialize in DPI (deep packet inspection) and IP classification software. Our technology identifies application flows to prioritize traffic and analyze usage.

And we think that DPI and traffic classification are a good fit with NFV. If you have a look at Qosmos today, we sell software building blocks. Our customers are equipment manufacturers that need real-time traffic visibility inside their products. We are an OEM player and we found that NFV is a great way for us to propose new form factors for our technology.

Little by little we discovered that we can make a significant contribution in the NFV space. So just to give you examples, when we started we participated at the first NFV meeting in Nice, France. Everybody remembers that meeting because it was snowing big time there, which is very unusual in Nice. And, we introduced the concept of what we called VNF Components (VNFC), which is similar to micro services.

Back in 2012, people were already saying let’s take our existing code base and let’s put it on an x86 and make it run in this virtualized infrastructure. That was the very first move to NFV. But what we saw is that it was a great opportunity as well to disaggregate this big siloed application and to decompose it into smaller elements. So that’s where this VNFC concept comes from, and this is why if you have a look at the ETSI NFV specs that were available in phase number one you will find the DPI VNFC is a key element of the architecture of NFV.

So really our roots in NFV are software. NFV makes us able to offer components as opposed to vertical applications and VNFC is really the first step there. Does that make sense to you, Prayson?

Prayson: Yes it does. As you pointed out, what you’re coming in with deep packet inspection is quite different than the other monolithic VNFs that people are talking about. You really focused on a component. So can you speak to a little bit about the network services that a DPI component can enable in terms of end users? And also, what benefit does it bring to the operators in terms of advanced analytics or network management?

Jerome: You are right. DPI and classification of IP traffic can enable many use cases. So, if you look at the leading use cases today, I would certainly speak about virtual EPC and PCEF — being able to do different kinds of traffic shaping, applications recognition for P-GW and mobile networks. Mobile is definitely an important use case for DPI-based classification.

Another important use case is reporting analytics such as quality of experience. Telcos really need to better understand the perceived quality of experience by end users on a per-application basis. DPI software is absolutely key for this use case as well. Then I would mention use cases that involve security, for example, a next generation firewall needs to block or allow certain traffic flows.

Now if we move to virtual CPE, DPI is needed for use cases such as reporting. Network managers would like to better understand what applications are being used in the enterprise and which of these could be deployed as a virtual CPE — traffic shaping, quality of service, and next generation firewall. Then, outside NFV we are seeing a lot of traction as well in Wi-Fi access points and Wi-Fi controllers.

Now one of the pain points I see is that today service providers can have several DPI stacks in their network: for packet shaping, for security, and for analytics. So these are three very basic examples that you will find deployed.

Here is the issue: Let’s assume you, Prayson, go on YouTube. Netscout, which might be used for reporting, will say, “Prayson went on YouTube and here is the quality of experience that was perceived.” Then you go to the traffic shaping solution, which could be something like Sandvine, and it would say, “I saw a flow which was Google Video.” And, then you check your next generation firewall, and the very same flow will be described as HD video streaming.

So these three situations could be true because it’s YouTube, it’s Google Video and it’s HDTV streaming. But you have three different descriptions of the very same traffic flow. In terms of management of your network, it’s an issue because ideally what you’d like to have is a single DPI-based classification component which gives you coherent information across different solutions.

That’s why we believe DPI shouldn’t be seen a vertical solution but actually as a horizontal software and classification results should be shared among different network functions in the network.

NFV is a very good mechanism for us to enable the new approach of shared DPI and classification information among different VNFs. And to be more specific, the service function chaining working group is a good start.

Prayson: You mentioned a couple of obstacles that your solution is working to address. The first one is today’s construction of VNFs as monolithic functions residing in virtual machines. And you talked about the need to really look at them as being constructed from smaller pieces perhaps moving to containers. Then the other point you mentioned was that DPI today is siloed and needs to be horizontal. So are those the main obstacles you’re helping to overcome? Are there others your company is helping to solve?

Jerome: One of the obstacles is to see DPI and classification as data plane technology only, uncorrelated from the management and control plane. I can give you a concrete example. Qosmos is contributing to the OpenDaylight service function chaining project. OpenDaylight is absolutely not about data plane. It’s really about management APIs and control plane. What we have done in this project is to extend the definition of service chains with application ID.

People operating the network must be able to manage DPI and classification functionality using standard tools. So we are involved in several management projects in OpenStack, in OpenDaylight and all of that to make sure there is an end-to-end vision of DPI being part of the infrastructure.

Prayson: That’s a great point. To implement true service chaining you need not only the DPI but the ability to tag the flows and to tie it to the higher level control. And, I see you’re actively involved in that. Based on the work that you’ve been doing in these various forums as well as with your customers, when do you think that NFV is going to hit critical mass for carrier-class networks and services?

Jerome: I don’t have a crystal ball. I would need that to predict the timing of NFV!

Prayson: Don’t we all.

Jerome: At the beginning we thought that Gi-LAN was a killer application for service providers. But then we realized that it’s not only about technology. It’s also the OSS, the BSS and how the service provider manages that, from an organizational point of view. That’s one of the reasons why it is quite slow.

We are now seeing people looking at deploying NFV for use cases that are less tightly connected with OSS and BSS, which are easier to deploy and where the ROI is shorter. So we see vCPE as one of the leading use cases for NFV, with POCs happening today and in 2016. If I am realistic, I would say that it could happen in 2017, perhaps end of 2016. But I don’t see it at the beginning of 2016.

Prayson: You mentioned the difficulty of getting things going based on integration with OSS and BSS systems and I’ve heard that from many people. Would you say that’s the thing that was the most surprising as you started work with your customers on NFV? Was there something else that was more surprising?

Jerome: There are many surprising things in NFV and that’s one of them. But I see other surprising things. When we had discussions with service providers at the beginning the big story about NFV was to disaggregate networks and instead of buying siloed applications from one vendor, people wanted to buy building blocks and connect them with open APIs. That was the initial dream.

Now I see plenty of building blocks available on the market and plenty of players, but some service providers are looking at pre-packaged solutions made of integrated building blocks. It’s not that they would like to come back to the old world, but they are not looking at buying building blocks from vendors A-B-C. They are looking for integrators who are able to integrate all this stuff. And to buy a solution already integrated as opposed to buying a bunch of building blocks.

So that’s a bit of a surprise because they are not executing what we thought about two years back. My feeling is what they are looking for now is pre-packaged solutions. So that’s an interesting move.

Another thing that is surprising is that open source doesn’t mean that things move faster. Actually sometimes it’s faster with proprietary than with open source. NFV is fully open, OpenStack is fully open, but technology is not moving as fast as we would like. This is a bit of a surprise. At the beginning I was under the impression that probably with this open development model things would go a bit faster than they are.

Prayson: Those are great points. Let me ask a follow-up on your comments about the integrated solution versus assembling their own components. What we’re seeing is that some of the larger operators, the Tier Ones, are still on this mindset that they want to assemble components themselves and do more in terms of programming. But the Tier Twos and especially the Tier Three operators are looking for a complete solution. Now, they like the fact that this is built as software components on an open platform. But, they still would like the whole thing delivered. Does that match your observations?

Jerome: Absolutely. I would add another point: because technology is not yet completely mature it seems that the very first version of NFV might be what I call “siloed” NFV. The typical example is a large vendor with its own NFV infrastructure and its own VNFs, all of that integrated on its own x86-based hardware. So the very first deployment of NFV might be siloed NFV, based on NFV principles and NFV technology, but not assembled from different suppliers.

Prayson: We’re seeing much the same thing from some of the traditional equipment providers who were doing exactly what you said. But I would point out that with Masergy, Overture and some of our partners have deployed pure-play virtualization in a virtual CPE application at the customer prem. The thing that was attractive to Masergy, and what they have publically stated is that they wanted a solution that was truly open. They did not like these closed solutions. So I think some of the traditional equipment providers are going to have to embrace the move away from, as you call it, a siloed deployment into more of an open deployment.

Jerome: I wouldn’t complain against equipment manufacturers because I think the technology is not yet completely mature. I think some of the technologies are mature, some are less mature. And, today it is very hard to deliver a full solution that is completely open. Part of the reason we have siloed NFV is because the equipment providers want to protect their business. But another part of the reason is that the technology is not mature, so it is easier for service providers to buy pre-packaged solutions.

Prayson: That’s a good summary.

Jerome: One point I’d like to make was already stated by Martin Taylor of Metaswitch, and I agree with him completely. We are seeing the very first generation of VNFs. We now need to have a second generation of VNFs, which will be designed from inception for the NFV architecture, which was not the case for this first generation. This will require new APIs provided by the NFVI and a new way of designing applications that will unlock a lot of potential for this NFV world. Like sharing DPI-based classification results between multiple VNFs or including linear scalability, based on the Ceilometer framework. Really, we need to redesign some applications to really unlock the potential of the NFV infrastructure.

Prayson: That’s a very good observation, and I have been hearing that more and more recently. I’ve heard one operator say that we really need to be moving from virtualization to cloudification. And virtualization really implies that first generation of VNF where you’re compiling and running in a VM. With cloudification you’re doing a disaggregation, where you’re designing for scalability, where you’re designing for data center, and where you’re designing to take advantage of these new development methods and open APIs. So I agree wholeheartedly that is the next step of where we need to go.

This has been very helpful. Jerome, I appreciate your time very much.

Jerome: Thank you!

For other entries in the Real CTOs of NFV series, please click here.